draft-ietf-dkim-overview-04.txt   draft-ietf-dkim-overview-05.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational D. Crocker Intended status: Informational D. Crocker
Expires: September 5, 2007 Brandenburg InternetWorking Expires: December 13, 2007 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
March 4, 2007 June 11, 2007
DomainKeys Identified Mail (DKIM) Message Signing Service Overview DomainKeys Identified Mail (DKIM) Overview
draft-ietf-dkim-overview-04 draft-ietf-dkim-overview-05
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 September 5, 2007. This Internet-Draft will expire on December 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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. [RFC4871] DKIM defines a domain-level authentication
authentication framework for email using public-key cryptography and framework for email using public-key cryptography and key server
key server technology. This permits verifying the source or technology. This permits verifying the source or intermediary for a
intermediary for a message, as well as the contents of messages. The message, as well as the contents of messages. The ultimate goal of
ultimate goal of this framework is to permit a signing domain to this framework is to permit a signing domain to assert responsibility
assert responsibility for a message, thus proving and protecting the for a message, thus proving and protecting the identity associated
identity associated with the message and the integrity of the with the message and the integrity of the messages itself, while
messages itself, while retaining the functionality of Internet email retaining the functionality of Internet email as it is known today.
as it is known today. Such protection of email identity, may assist Such protection of email identity may assist in the global control of
in the global control of "spam" and "phishing". This document "spam" and "phishing". This document provides an overview of DKIM,
provides an overview of DKIM and describes how it can fit into a describes how it can fit into a messaging service, describes how it
messaging service, how it relates to other IETF message signature relates to other IETF message signature technologies, and includes
technologies. It also includes implementation and migration implementation and migration considerations.
considerations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. DKIM Framework . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The DKIM Value Proposition . . . . . . . . . . . . . . . . 5 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Function . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Service Architecture . . . . . . . . . . . . . . . . . . . 13
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Deployment and Operation of DKIM Base . . . . . . . . . . . . 15
2.1. Treat verification failure as if unsigned. . . . . . . . . 7 2.1. Development . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. Domain-level assurance . . . . . . . . . . . . . . . . . . 7 2.2. Email Infrastructure Agents . . . . . . . . . . . . . . . 16
2.3. Incremental adoption . . . . . . . . . . . . . . . . . . . 7 2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Minimal infrastructure . . . . . . . . . . . . . . . . . . 8 2.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5. Transparent signature . . . . . . . . . . . . . . . . . . 8 2.5. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6. Security policy . . . . . . . . . . . . . . . . . . . . . 9 2.6. On-going Operations . . . . . . . . . . . . . . . . . . . 24
3. Function and Use . . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 27
3.1. What is a DKIM signature? . . . . . . . . . . . . . . . . 9 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
3.2. The Selector construct . . . . . . . . . . . . . . . . . . 9 4. Informative References . . . . . . . . . . . . . . . . . . . . 29
3.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4. What does DKIM NOT do? . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 32
3.5. Does DKIM eliminate anonymity for email? . . . . . . . . . 11
4. DKIM Within Existing Internet Email . . . . . . . . . . . . . 11
4.1. Review of Internet Mail Service Architecture . . . . . . . 11
4.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 14
4.3. Impact on Email Activities . . . . . . . . . . . . . . . . 15
4.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 17
5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 18
6. Development . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Coding Criteria for Cryptographic Applications . . . . . . 20
6.2. Email Infrastructure Agents . . . . . . . . . . . . . . . 21
6.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 22
6.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 25
7.4. Transition strategy . . . . . . . . . . . . . . . . . . . 25
8. On-going Operations . . . . . . . . . . . . . . . . . . . . . 27
8.1. DNS Signature Record Deployment Considerations . . . . . . 27
8.2. Private Key Management . . . . . . . . . . . . . . . . . . 29
8.3. Mailing list manager developers . . . . . . . . . . . . . 29
9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Protection of Internal Mail . . . . . . . . . . . . . . . 30
9.2. Recipient-based Assessments . . . . . . . . . . . . . . . 30
9.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 31
9.4. Per user signature . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
11. { Misc Text -- Should go elsewhere, if used at all } . . . . . 32
12. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. DKIM Framework
1.1. Introduction
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. [RFC4871] DKIM accomplishes this by defining a
authentication framework for email using public-key cryptography and domain-level authentication framework for email using public-key
key server technology. This permits verifying the source or cryptography and key server technology. This permits verifying the
intermediary for a message, as well as the contents of messages. The source or intermediary for a message, as well as the contents of
ultimate goal of this framework is to permit a signing domain to messages. DKIM will also provide a mechanism that permits potential
assert responsibility for a message, thus proving and protecting the email signers to publish information about their email signing
practices; this will permit email receivers to make additional
assessments of unsigned messages.
The ultimate goal of this framework is to permit a domain to assert
responsibility for a message, thus proving and protecting the
identity associated with the message and the integrity of the identity associated with the message and the integrity of the
messages itself, while retaining the functionality of Internet email messages itself, while retaining the functionality of Internet email
as it is known today. Such protection of email identity, may assist as it is known today. Such protection of email identity, may assist
in the global control of "spam" and "phishing". This document in the global 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
technologies. It also includes implementation and migration
considerations.
This document provides an overview of DomainKeys Identified Mail This document provides a description of DKIM's architecture,
(DKIM). It is intended for those who are adopting, developing, or functionality, deployment and use. It is intended for those who are
deploying DKIM. It also will be helpful for those who are adopting, developing, or deploying DKIM. It also will be helpful for
considering extending DKIM, either into other areas or to support those who are considering extending DKIM, either into other areas of
additional features. This Overview does not provide information on use or to support additional features. This Overview does not
threats to DKIM or email, or details on the protocol specifics, which provide information on threats to DKIM or email, or details on the
can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats], protocol specifics, which can be found in [RFC4871] and [RFC4686],
respectively. The document assumes a background in basic network respectively. The document assumes a background in basic network
security technology and services. security technology and services.
It must be stressed that neither this document nor DKIM attempt to It must be stressed that neither this document nor DKIM attempt to
provide solutions to the world's problems with spam, phish, virii, provide solutions to the world's problems with spam, phish, virii,
worms, joe jobs, etc. DKIM creates one basic tool in what needs to worms, joe jobs, etc. DKIM provides one basic tool, in what needs to
be a large arsenal of tools, for improving the safety of Internet be a large arsenal, for improving the safety of Internet mail.
mail. However by itself, DKIM is not sufficient to that task and However, by itself, DKIM is not sufficient to that task and this
this Overview does not pursue the issues of integrating DKIM into overview does not pursue the issues of integrating DKIM into these
these larger efforts. Rather, it is a basic introduction to the larger efforts. Rather, it is a basic introduction to the technology
technology and its deployment. and its deployment.
1.1. Background
There have been four other efforts at standardizing an email
signature scheme:
o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989]
o PEM eventually transformed into MIME Object Security Services in
1995 [RFC1848]. Today, these two are only of historical interest.
o Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
first released in 1991.[RFC1991] A later version was standardized
as OpenPGP. [RFC3156]
o RSA Security, the holder of the patent rights to the principle
public key cryptography algorithm, independently developed Secure
MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851]
Development of S/MIME and OpenPGP has continued. While both have
achieved a significant user base, neither has achieved ubiquity in
deployment or use and their goals differ from those of DKIM.
In principle the S/MIME protocol can support semantics such as domain
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.
Unlike 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.
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 layered on UDP and key retrieval is
typically achieved in a single round trip.
1.2. The DKIM Value Proposition
Spam can be understood as two separate problems. The first is the
problem of companies that are inappropriately aggressive, in sending
out unsolicited marketing email. This accounts for, perhaps, 5% of
the spam volume and is in any case usually handled by existing spam
filters. [N.B. need a reference for the 5%.] 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.
DKIM provides a means of associating a verifiable identity with a
message. Given the presence of that identity, a receiver can make
decisions about further handling of the message, based upon
assessments of that identity.
For messages that produce a valid signature, it will be possible to
make affirmative trust assessments. For messages using identities
that are typically signed, it will be possible to detect some types
of phishing emails and block them.
1.3. Phishing
The value of a cousin domain, that could be mistaken for the 1.1.1. The DKIM Value Proposition
legitimate domain, is significantly reduced if the number of emails
that can be successfully sent from it is small.
Phishing attacks are typically made against trusted brands, that is, The nature and origins of a message are often falsely stated. As a
names that are closely affiliated with well-known organizations. A foundation for distinguishing legitimate mail, DKIM provides a means
DKIM-based accreditation service can enforce a basic separation of associating a verifiable identity with a message. Given the
between domains used by such known organizations and domains used by presence of that identity, a receiver can make decisions about
others. further handling of the message, based upon assessments of that
identity.
Receivers who successfully validate a signature can use information Receivers who successfully verify a signature can use information
about the signer as part of a program to limit spam, spoofing, about the signer as part of a program to limit spam, spoofing,
phishing, or other undesirable behavior, although the DKIM phishing, or other undesirable behavior. DKIM does not, itself,
specification itself does not prescribe any specific actions by the prescribe any specific actions by the recipient; rather it is an
recipient. enabling technology for services that do.
1.4. Conventions
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 [RFC2822] and <RFC2821.MailFrom> is the address in the
SMTP "Mail From" command. [RFC2821]
This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org.
2. Goals
DKIM lets an organization take responsibility for a message. The
organization taking responsibility typically is a handler of the
message, either as its originator or as an intermediary. It can also
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
declaring that they are accountable for the message. This means that
their reputation is at stake.
By design, DKIM purposely:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible
o requires minimal new infrastructure
o can be implemented independently of clients in order to reduce
deployment time
o does not require the use of new trusted third parties (e.g.,
certificate authorities) that might impose significant costs or
introduce delays to deployment
o can be deployed incrementally, with separate deployment of signers
and verifiers in either order
o allows delegation of signing to third parties
o is not intended be used for archival purposes
DKIM authentication provides one link in a chain of responsibility,
hopefully leading to better accountability by the senders.
2.1. Treat verification failure as if unsigned.
PGP and S/MIME were both designed for strong cryptographic
protection. This included treating validation failure as message
failure. For DKIM, the guidance is that an email signature verifier
is to treat messages with signatures that fail as if they were
unsigned. Hence the message will revert to normal handling, through
the receiver's existing filtering mechanisms.
2.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.
2.3. Incremental adoption
DKIM can immediately provide benefits 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.
Although it is envisioned that this mechanism will call upon
independent assessment services, they are not essential in order to
obtain initial benefit. For example DKIM 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 some spam filters. In effect the email receiver is
using their set of known relationships to generate their own
accreditation/reputation data. This works particularly well for
traffic between large sending 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.
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.
2.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.
2.5. Transparent signature
S/MIME and PGP 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 to
recipients that do not support it.
2.6. Security policy These services will typically:
DKIM separates basic authentication from policy. An authenticated 1. Verify an identity
identity may be subject to a variety of processing policies, either
ad hoc or standardized. The only policy inherent in a DKIM signature
is that the signer is asserting (some) responsibility for the
message. Other possible policies to consider developing include
asserting a relationship between the signing identity and the author
(RFC 2822 From) domain identity, as well as whether to tread unsigned
message with that From domain as problematic. It would, therefore,
be helpful for a potential signer to be able to publish various
policies, to permit a receiver to know more about the signer's
practices
3. Function and Use 2. Determine whether the identity is known or unknown
DKIM has a very constrained set of capabilities, primarily targeting 3. Determine whether a known identity is trusted
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
responsibility for the presence of a message in the mail stream. A
responsible organization adds a digital signature to the message,
associating it with a domain name of that organization. Typically,
signing will be done by a service agent within the authority of the
message originator's Administrative Management Domain (ADMD).
(Signing might be performed by any of the functional components in
that environment, including a Mail User Agent (MUA), a Mail
Submission Agent (MSA), or an Internet Boundary MTA. DKIM also
permits signing to be performed by authorized third-parties.)
3.1. What is a DKIM signature? An attack is made against an organization or against customers of an
organization. The name of the organization is linked to particular
Internet domain names. One point of leverage used by attackers is
either to spoof a legitimate domain name, or to use a "cousin" name
that is similar to one that is legitimate, but is not controlled by
the target organization. A DKIM-based accreditation service can
enforce a basic separation between domains used by such known
organizations and domains used by others.
A signature covers the message body and selected header fields. The DKIM signatures can be created by a direct handler of a message,
signer computes a hash of the selected header fields and another hash either as its originator or as an intermediary. It can also be
of the body. They then use a private key to cryptographically encode created by an independent service, providing assistance to a handler
this information, along with other signing parameters. The signature of the message. Whoever does the signing chooses the domain name to
information is placed into a new header field of the [RFC2822] be used as the basis for later assessments. Hence, reputation
message. associated with that domain name 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 declaring that they are
accountable for the message.
3.2. The Selector construct DKIM is intended to be a value-added feature for email. Mail that is
not signed by email is handled in the same way as it now is; it
continues to be evaluated by established analysis and filtering
techniques. Over time, widespread DKIM adoption could permit
degraded handling of messages that are not signed. However early
benefits do not require this more-stringent enforcement.
For a single domain, DKIM permits use of multiple signing keys and/or It is important to be clear about the narrow scope of DKIM's
multiple signers. To do this, DKIM identifies a particular signature capabilities. It is an enabling technology, intended for use in the
as a combination of the domain name and an added field, called the larger context of determining message legitimacy. This larger
"selector". Both of these are coded into the DKIM-Signature header context is complex, so that it is easy to assume that a component
field. like DKIM, which actually provides only a limited service, instead
satisfies the broader set of requirements. A DKIM signature :
Selectors are assigned according to the administrative needs of the o Does not offer any assertions about the behaviors of the identity
signing domain, such as for rolling over to a new key or for doing the signing.
delegating of the right to authenticate a portion of the namespace to
a trusted third party.
Examples include: jun2005.eng._domainkey.example.com o Does not prescribe any specific actions for receivers to take upon
successful (or unsuccessful) signature verification.
widget.promotion._domainkey.example.com o Does not provide protection after signature verification.
NOTE: It is intended that assessments of DKIM identities be o Does not protect against re-sending (replay of) a message that
based on the domain name, and not include the selector. This already has a verified signature; therefore a transit intermediary
permits the selector to be used only for key administration, or a recipient can re-post the message in such a way that the
rather than having an effect on reputation assessment. signature would remain verifiable, although the new recipient(s)
would not have been specified by the originator.
3.3. Validation 1.1.2. Prior Work
After a message has been signed, any agent in the message transit Historical email assessment based on identity has been based on the
path can choose to validate the signature, to determine that the IP Address of a system that sent the message. The Address is
signing identity took responsibility for the message. Message obtained via underlying Internet information mechanisms and is
recipients can verify the signature by querying the signer's domain therefore trusted to be accurate. Besides having some known security
directly to retrieve the appropriate public key, and thereby confirm weaknesses, the use of Addresses present a number of functional and
that the message was attested to by a party in possession of the operational problems. Consequently there is an industry desire to
private key for the signing domain. Typically, validation will be use a more stable value that has had better correspondence with
done by an agent in the ADMD of the message recipient. organizational boundaries. Domain Names are viewed as satisfying
this need.
3.4. What does DKIM NOT do? There have been four previous efforts at standardizing an Internet
email signature scheme:
A DKIM signature does not: o Privacy Enhanced Mail (PEM) was first published in 1987.
[RFC0989]
o offer any assertions about the behaviors of the identity doing the o PEM eventually transformed into MIME Object Security Services in
signing. 1995. [RFC1848] Today, these two are only of historical interest.
o prescribe any specific actions for receivers to take upon o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
successful (or unsuccessful) signature validation. first released in 1991. [RFC1991] A later version was
standardized as OpenPGP. [RFC2440] [RFC3156]
[I-D.ietf-openpgp-rfc2440bis]
o provide protection after message delivery. o RSA Security independently developed Secure MIME (S/MIME) to
transport a PKCS #7 data object. [RFC3851]
o protect against re-sending (replay of) a message that already has Development of S/MIME and OpenPGP have continued. While both have
a valid signature; therefore a transit intermediary or a recipient achieved a significant user base, neither have achieved ubiquity in
can re-post the message in such a way that the signature would deployment or use, and their goals differ from those of DKIM.
remain valid, although the new recipient(s) would not have been
specified by the originator.
3.5. Does DKIM eliminate anonymity for email? To the extent that other message-signing services might have been
adapted to do the job that DKIM is designed to perform, it was felt
that re-purposing any of those would be more problematic than
creating a separate service. That said, DKIM uses security algorithm
components that have a long history, including use within some of
those other messaging security services.
The ability to send a message that does not identify its author is DKIM has a distinctive approach for distributing and vouching for
considered to be a valuable quality of the current email system. It keys. It uses a key-centric Public Key Infrastructure (PKI) rather
turns out that DKIM is particularly helpful to this goal, because a than the more typical approaches based on a certificate in the styles
DKIM signature will typically be used to identity an email system of Kohnfelder (X.509) or Zimmermann (web of trust). For DKIM, the
operator, rather than a content author. Knowing that a mail owner of a key asserts its validity, rather than relying on the key
definitely came from example.com does not threaten the anonymity of having a broader semantic implication of the assertion, such as a
the user, if it is still possible to obtain effectively anonymous quality assessment of the key's owner. DKIM treats quality
accounts at example.com and other web mail providers. assessment as an independent, value-added service, beyond the initial
work of deploying a verifying signature service.
4. DKIM Within Existing Internet Email Further, DKIM's PKI is supported by adding additional information
records to the existing Domain Name Service (DNS) [RFC1034], rather
than requiring deployment of a new query infrastructure. This
approach has significant operational advantages. First, it avoids
the considerable barrier of creating a new infrastructure; hence it
leverages a global base of administrative experience and highly
reliable distributed operation. Second, the technical aspect of the
DNS is already known to be efficient. Any new service would have to
undergo a period of gradual maturation, with potentially problematic
early-stage behaviors. By (re-)using the DNS, DKIM avoids these
growing pains.
4.1. Review of Internet Mail Service Architecture 1.1.3. Internet Mail Background
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 other users, creating a virtual MUA- and delivering it to one or more other users, creating a virtual MUA-
to-MUA exchange environment. The first MTA is called the Mail to-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 | . .
. +--------+ . .
. ^ . .
. . . .
V . . .
+---+----------------+------+------+---+
| . . . . |
| +...............>+ . . |
| . . . |
| +......................>+ . |
| . . |
| +.............................>+ |
| |
| Mail Handling Service (MHS) |
+--------------------------------------+
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.
4.1.1. Administrative Actors 1.1.3.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). An ADMD operates with an ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust. Examples include an end- 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 that connects to an independent
Relay, an IT department operating an enterprise Relay and an ISP email service, a department operating a submission agent or a local
operating a public shared email service. These can be configured Relay, an organization's IT group that operates enterprise Relays,
into many combinations of administrative and operational and an ISP operating a public shared email service.
relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the Each of these can be configured into many combinations of
relationships among ADMDs. Perhaps the most salient aspect of an administrative and operational relationships, with each ADMD
ADMD is the differential trust that determines its policies for potentially having a complex arrangement of functional components.
activities within the ADMD, versus those involving interactions with Figure 1 depicts the relationships among ADMDs. Perhaps the most
other ADMDs. 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: Basic components of ADMD distinction include:
Edge: Independent transfer services, in networks at the edge of Edge: Independent transfer services, in networks at the edge of
the Internet Mail service. the Internet Mail service.
User: End-user services. These might be subsumed under an Edge User: End-user services. These might be subsumed under an Edge
service, such as is common for web-based email access. service, such as is common for web-based email access.
Transit: These are Mail Service Providers (MSP) offering value- Transit: These are Mail Service Providers (MSP) offering value-
skipping to change at page 13, line 40 skipping to change at page 8, line 26
| V | | | +-------+ +-------+ | V | | | +-------+ +-------+
| Edge--+---+ | | Edge--+---+ |
| | | +---------+ | | | | +---------+ |
+-------+ | | ADMD2 | | +-------+ | | ADMD2 | |
| | ----- | | | | ----- | |
| | | | | | | |
+--->|-Transit-+---+ +--->|-Transit-+---+
| | | |
+---------+ +---------+
Figure 2: ADministrative Management Domains (ADMD) Example Figure 1: 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: Operating an organization's Enterprise Service Providers: Operators of an organization's
internal data and/or mail services. internal data and/or mail services.
Internet Service Providers: Operating underlying data Internet Service Providers: Operators of underlying data
communication services that, in turn, are used by one or more communication services that, in turn, are used by one or more
Relays and Users. It is not necessarily their job to perform Relays and Users. It is not necessarily their job to perform
email functions, but they can, instead, provide an environment email functions, but they can, instead, provide an environment
in which those functions can be performed. in which those functions can be performed.
Mail Service Providers: Operating email services, such as for Mail Service Providers: Operators of email services, such as for
end-users, or mailing lists. end-users, or mailing lists.
4.2. Where to Place DKIM Functions 1.1.4. Conventions
Deciding which ADMD shall perform signing or verifying, which In this document, references to structured fields of a message use a
identity to assign and which functional components to use for DKIM two-part dotted notation. The first part cites the document that
processing depends upon the nature of the trust/reputation that is of contains the specification for the field and the second is the name
interest and the most convenient or efficient way to use it. of the field. Hence <RFC2822.From> is the From field in an email
Messages may be signed or verified by any functional component within content header [RFC2822] and <RFC2821.MailFrom> is the address in the
an ADMD, as that domain wishes to arrange. Examples include: SMTP "Mail From" command. [RFC2821]
Outbound: MUA, MSA or boundary MTA. This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org.
Inbound: Boundary MTA, MDA or MUA. 1.2. Goals
By having an MUA do the signing or verifying, there is no dependence DKIM seeks to add authentication to the existing email transfer
upon implementation by an email service infrastructure. By having an infrastructure. This motivates functional goals about authentication
MHS component do signing or verifying, there is no dependence upon and operational goals about integration with the existing email
user training or the upgrade of potentially large numbers of user service.
applications.
For implementation by an ADMD's email service operators, perhaps the 1.2.1. Functional
most obvious choices within the MHS are the MSA or MDA, and the
outbound or inbound (boundary) MTA. By signing or verifying at the
MSA and MDA, respectively, this outermost portion of the MHS provides
true end-to-end service, and requires the smallest amount of trust of
the intervening service infrastructure. By signing or verifying at a
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 Use Domain-level granularity for assurance. OpenPGP and S/MIME
include: 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. Further DKIM signing and/or validating may be implemented
anywhere along the transit path, rather than only in the end
systems.
Author: The domain associated with the RFC2822.From field Allow delegation of signing to independent parties. Different
provides basic authorization for the author to generate mail. parties have different roles in the process of email exchange.
Because the organization controlling that domain is closest to Some of these parties are easily visible to end users and others
the author, they well might be in the best position to offer are primarily visible to operators of the service. DKIM needs to
their reputation as a basis for asserting that the content is support signing by any of these different parties and needs to
"safe". permit them to sign with any domain name that they deem
appropriate. As an example an organization that creates email
content often delegates portions of its processing or transmission
to an outsourced group. DKIM must support this mode of activity,
in a manner that is not visible to end users.
Operator: Email recipient services have long-used the IP Address Distinguish the core authentication mechanism from its derivative
of a client SMTP server as the basis for assessing whether to uses. An authenticated identity may be subject to a variety of
permit relay or delivery of a message. These Addresses processing policies, either ad hoc or standardized. The only
identify the operator of an email service, rather than semantics inherent to a DKIM signature is that the signer is
necessarily indicating the author of messages being sent by asserting (some) responsibility for the message. All other
that service. Use of an operator's domain name is a natural mechanisms and meanings are independent of this core service. One
extension of this model. such mechanism might assert a relationship between the signing
identity and the author (<RFC2822.From>) domain identity. Another
might specify how to treat an unsigned message with that
<RFC2822.From> domain.
Third-party: An independent service might wish to certify an Retain ability to have anonymous email. The ability to send a
author, a message or an operator, by providing its own message that does not identify its author is considered to be a
signature to a message. Hence, evaluation of the message will valuable quality of the current email system that needs to be
be based upon the identity of that third-party, rather than any retained. DKIM is compatible with this goal since it permits an
of the identities involved in creating or transferring the email system operator to be authenticated, rather than the content
message. Indeed, this model is already emerging among a number author. Knowing that a mail definitely came from example.com does
of reputation-vetting services and is similar to the way a not threaten the anonymity of the user, if it is still possible to
credit card permits a customer to make purchases, based upon obtain effectively anonymous accounts at example.com and other
the reputation of the credit card company -- and its mail providers.
willingness to issue the card.
Ultimately, deciding where to sign a message will depend upon both 1.2.2. Operational
the identity being used and tradeoffs among flexibility of uses,
administrative control, and operational control. Deciding where to
verify a message will depend upon the intended use and similar
concerns about flexibility and control. A typical choice for
reputation-related verification will be to place the signature
verification function "close" to the message-filtering engine.
4.3. Impact on Email Activities Make signature transparent to non-supporting recipients. S/MIME and
OpenPGP both modify the message body. Hence, their presence is
potentially visible to 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 to recipients that do not support it.
4.3.1. Resources Treat verification failure the same as no signature unsigned.
OpenPGP and S/MIME were both designed for strong cryptographic
protection. This included treating verification failure as
message failure. As a sub-goal to the requirement for
transparency, a DKIM signature verifier is to treat messages with
signatures that fail as if they were unsigned. Hence the message
will revert to normal handling, through the receiver's existing
filtering mechanisms.
Although public-key cryptographic authentication is considered to be Permit incremental adoption for incremental benefit. DKIM can
computationally expensive, the real impact of a mechanism like DKIM immediately provide benefits between any two organizations that
can be remarkably small. Direct impact on CPU-load has been measured exchange email and implement DKIM. In the usual manner of
to be 10-15%. Mail handling tends to be I/O-intensive, so that "network effects", the benefits of DKIM increase dramatically as
dedicated email platforms tend to have unused computational capacity. its adoption increases.
It is therefore likely that no new hardware will be required for
these systems to be able to add DKIM support.
4.3.2. Operations Although it is envisioned that this mechanism will call upon
independent services to aid in the assessment of DKIM results,
they are not essential in order to obtain an initial benefit. For
example DKIM allows (possibly large) pair-wise sets of 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 some
spam filters. In effect the email receiver is using their set of
known relationships to generate their own accreditation/reputation
data. This works particularly well for traffic between large
sending 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.
The costs to deploy, administer and operate DKIM vary greatly, Minimize the amount of required infrastructure. A new service, or
depending upon the placement of DKIM-related modules. The greatest an enhancement to an existing service, requires adoption by some
flexibility comes from placing the modules as close as possible to number of systems, before it can be useful. The greater the
the end user. However this also imposes the greatest costs. The number of required adopters, the higher the adoption barrier.
most common scenarios are likely to be: This becomes particularly serious when adoption is required by
intermediary -- that is, infrastructure -- service providers. In
order to allow early adopters to gain early benefit, DKIM seeks to
make no changes to the core Internet Mail service and, instead, to
allow a useful benefit for any signer/verifier pair of
participants exchanging mail.
Boundary MTA: Here, DKIM is used only for email external to the Similarly, DKIM's reliance on the Domain Name Service greatly
ADMD. Administration and operation is the simplest, but could reduces the amount of new administrative infrastructure that must
cause problems for mobile users who are associated with the be deployed over the open Internet.
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..
MSA/MDA (Department): Placing DKIM support at the points of Permit wide range of deployment choices. It should be possible to
submission and delivery increases the deployment costs but implement DKIM at a variety of places within an organization's
still keeps control within the ADMD's operational staff. It email service. This permits the organization to choose how much
avoids the considerable, added costs of having to enhance all or how little they want DKIM to be part of their service, rather
of the MUAs. This does not improve the lot of mobile users who than part of a more localized operation.
submit from independent MSAs, but does provide full protection
within the ADMD.
MUA: Obviously this can provide the most complete protection, 1.3. Function
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.
4.3.3. Mobile Users DKIM has a very constrained set of capabilities, primarily targeting
email while it is in transit, from an originator to a set of
recipients. It creates the ability to associate verifiable
information with a message, especially a responsible identity. When
a message is not signed, DKIM permits the identity of the sender to
be used for obtaining information about their signing practices.
Mobile users often must post messages through MSAs that are not under 1.3.1. The Basic Signing Service
the control of the user's home ADMD. Placing DKIM signing into the
MUA is the only way to ensure that a highly mobile user retains all
of its benefits, in spite of having to send mail through these
independent MSAs. However this leads to the administrative overhead
of having a DKIM DNS key selector record for each mobile user. For
mail reading, no changes are needed.
4.3.4. Mailing Lists With the DKIM signature mechanism, a signer associates a domain name
with an address, performs digital signing on the message, and records
signature information in a DKIM header field. A verifier obtains the
domain name from the DKIM header field, queries for a public key
associated with the name, and verifies the signature.
A mailing list takes delivery of a message and reposts it, usually DKIM permits any domain name to be use for signing, and supports
with significant changes to the message. This will often break a extensible choices for various algorithms. As is typical for
DKIM signature, although DKIM has some features to survive simple Internet standards, there is a core set of algorithms required to be
mailing list modifications. For mailing lists that impose supported by all implementations. This ensures an initial ability to
substantial changes, it will be the responsibility of the list interoperate.
operator to add their own DKIM signature.
4.4. Migrating from DomainKeys 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.
4.4.1. Signing With DKIM the signer MUST explicitly list the headers that are
signed. By choosing the minimal set of headers needed the signature
is likely to be considerably more robust against the handling
vagaries of intermediary MTAs.
DNS Records: DKIM is upward compatible with existing DomainKeys 1.3.2. Characteristics of a DKIM signature
(DK) [I-D.delany-domainkeys-base] DNS records, so that a DKIM
module does not automatically require additional DNS
administration! However, it should be noted that DKIM has
enhanced the DomainKeys DNS key record format by adding several
optional parameters.
Boundary MTA: The principle use of DomainKeys is at Boundary A DKIM signature covers the message body and selected header fields.
MTAs. Because no operational transition is ever instantaneous, The signer computes a hash of the selected header fields and another
a signer SHOULD add a DKIM signature to a message that has a hash of the body. The signer then uses a private key to
DomainKeys signature, rather than replacing it, until such time cryptographically encode this information, along with other signing
as DomainKeys receive-side support is sufficiently reduced. parameters. Signature information is placed into a new [RFC2822]
With respect to signing policies, a reasonable, initial header field of the message.
approach is to use DKIM signatures in the same way as
DomainKeys signatures are already being use.
4.4.2. Verifying 1.3.3. The Selector construct
DNS Client: DNS queries for the DKIM key record, use the same A signature is associated with a domain name, as specified in the
Domain Name naming conventions and the same basic record "d=" DKIM parameter. That domain name is the complete identity used
format. No changes to the DNS client should be required. for making assessments about the signer. However this name is not
sufficient for making a query to obtain the key needed to verify the
signature.
Verifying module: See "Signing Module". A single domain can use multiple signing keys and/or multiple
signers. To support this, DKIM identifies a particular signature as
a combination of the domain name and an added field, called the
"selector". Both of these are coded into the DKIM-Signature header
field.
4.4.3. Boundary MTA It must be stressed that the selector is not part of the domain name
that is used for making assessments. Rather, the selector is
strictly reserved for use in administering keys that are associated
with the domain name. If the selector becomes part of a name
assessment mechanism, then there is no remaining mechanism for making
a transition from an old, or compromised, key to a new one.
Independent of whether a Boundary MTA is performing general message Signers do have the need for supporting multiple assessments about
filtering, a helpful practice is to have it check for DKIM signatures their organization, such as to distinguish one type of message from
that purport to be made with a domain name that belongs to the ADMD another, or one portion of the organization from another. To permit
of the Boundary MTA. If the signature does not validate, the MTA MAY assessments that are independent, an organization should use
decide to delete the signature. different sub-domains in the "d=" parameter, such as
"transaction.example.com" versus "newsletter.example.com", or
productA.example.com versus productB.example.com.
5. Service Architecture 1.3.4. Verification
DKIM provides an end-to-end service for signing and verifying After a message has been signed, any agent in the message transit
messages that are in transit. It is divided into components that can path can choose to verify the signature, to determine that the
be performed using different, external services (e.g., key signing identity took responsibility for the message. Message
retrieval), although the basic DKIM operation provides an initial recipients can verify the signature by querying the signer's domain
set. 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, verification will be
done by an agent in the ADMD of the message recipient.
1.4. Service Architecture
The DKIM service is divided into components that can be performed
using different, external services, such as for key retrieval.
However the basic DKIM signing specification defines an initial set
of these services, in order to ensure a basic level of
interoperability.
| |
| - RFC2822 Message | - RFC2822 Message
V V
+---------------------------------------------+ +------------------------------+
+-----------+ | ORIGINATING OR RELAYING ADMD | | ORIGINATING OR RELAYING ADMD |
| Signer | | ============================ | | |
| Practices +......>| SIGN MESSAGE | +..>| Sign Message |
+-----+-----+ | ...> ADD A SIGNATURE HEADER FIELD | . +--------------+---------------+
. ...>| . GET (Domain, Selector, Priv-Key) | . |
. / | ... COMPUTE SIGNATURE | .private |
. V +----------------+----------------------------+ +---+---+ | +-----------+
. +-------+ | - Message | Key | | | Sender |
. | Key | | 1*(Domain, Selector, | Store | [Internet] | Practices |
. | Store | [Internet] Sig) +---+---+ | +-----+-----+
. +---+---+ V .public | .
. . +---------------------------------------------+ . V .
. . | RELAYING OR DELIVERING ADMD | . +------------------------------+ .
. . | =========================== | . | RELAYING OR DELIVERING ADMD | .
. . | VERIFY MESSAGE (Verifier Practices) | . | | .
. . | ...> VERIFY A SIGNATURE HEADER FIELD | . | Message Signed? | .
. . | . GET A SIGNATURE | . +-------+----------------+-----+ .
. \...>| . LOOKUP PUB-KEY (Domain, Selector) | . |yes |no .
. | . VERIFY SIGNATURE VALUE | . V V .
. | ... EVALUATE SIGNATURE CONSTRAINTS | . +-----------+ +-----------+ .
. +-------------------+-------------------------+ +.....>| Verify | +..>| Check |<..+
. | - Verified Domain(s) | Signature | | | Practices |
. V - [Report] +---+-----+-+ | +---+-------+
. +---------------------------------------------+ | | | |
\............>| MESSAGE DISPOSITION | | +---+ |
............>| SIGNER PRACTICES | |pass fail |
/ | REPUTATION | V |
+-----+------+ +---------------------------------------------+ +--------+ |
| Reputation | +.......>| Assess | |
+------------+> . | Signer | |
. +---+----+ |
. assessment| |
. +------+ +------+
. | |
+-+----------+ V V
| Reputation | +-----------+
+-----+------+ | Message |
| Filtering |
| Engine |
+-----------+>
Figure 3: DKIM Service Architecture Figure 2: DKIM Service Architecture
Basic message processing is divided between signing the message, As shown in the Figure, basic message processing is divided between
validating the signature, and then making further decisions based signing the message, verifying the signature or determining whether a
upon the validated signature. The signing component applies whatever signature was required, and then making further decisions based upon
signing policies are in force, including ones that determine which the results. Signing may be performed by a component of the ADMD
private key to use. Validation may be performed by any functional that creates the message, and/or within any ADMD, along the relay
component along the relay and delivery path. Validators retrieve the path. The signer uses the appropriate private key.
public key based upon the parameters stored in the message. The
figure shows using the validated identity to assess an associated
reputation, but it could be applied to other tasks, such as
management tracking of mail.
6. Development Verification may be performed by any functional component along the
relay and delivery path. Verifiers retrieve the public key based
upon the parameters stored in the message. The figure shows the
verified identity as being used to assess an associated reputation,
but it could be applied for other tasks, such as management tracking
of mail.
6.1. Coding Criteria for Cryptographic Applications Note that a failed signature causes the message to be treated in the
same manner as one that is unsigned. Unsigned messages prompt a
query for any published "sender practices" information, as an aid in
determining whether the sender information has been used without
authorization.
For signature verification and for the assessment of unsigned
messages, the results of these processes are treated as additional
input to the receiver's filtering engine. The engine determines
message disposition, such as whether to deliver it.
2. Deployment and Operation of DKIM Base
2.1. Development
2.1.1. Coding Criteria for Cryptographic Applications
Correct implementation of a cryptographic algorithm is a necessary Correct implementation of a cryptographic algorithm is a necessary
but not a sufficient condition for coding of cryptographic but not a sufficient condition for the coding of cryptographic
applications. Coding of cryptographic libraries requires close applications. Coding of cryptographic libraries requires close
attention to security considerations that are unique to cryptographic attention to security considerations that are unique to cryptographic
applications. applications.
In addition to the usual security coding considerations, such as In addition to the usual security coding considerations, such as
avoiding buffer or integer overflow and underflow, implementers avoiding buffer or integer overflow and underflow, implementers
should pay close attention to management of cryptographic private should pay close attention to management of cryptographic private
keys and session keys, ensuring that these are correctly initialized keys and session keys, ensuring that these are correctly initialized
and disposed of. and disposed of.
skipping to change at page 20, line 43 skipping to change at page 16, line 21
performance benefits, many cryptographic hardware devices provide performance benefits, many cryptographic hardware devices provide
robust and verifiable management of private keys. robust and verifiable management of private keys.
Fortunately appropriately designed and coded cryptographic libraries Fortunately appropriately designed and coded cryptographic libraries
are available for most operating system platforms under license terms are available for most operating system platforms under license terms
compatible with commercial, open source and free software license compatible with commercial, open source and free software license
terms. Use of standard cryptographic libraries is strongly terms. Use of standard cryptographic libraries is strongly
encouraged. These have been extensively tested, reduce development encouraged. These have been extensively tested, reduce development
time and support a wide range of cryptographic hardware. time and support a wide range of cryptographic hardware.
6.1.1. Signer 2.1.2. Signer
Signer implementations SHOULD provide a convenient means of Signer implementations SHOULD provide a convenient means of
generating DNS key records corresponding to the signer configuration. generating DNS key records corresponding to the signer configuration.
Support for automatic insertion of key records into the DNS is also Support for automatic insertion of key records into the DNS is also
highly desirable. If supported however such mechanism(s) MUST be highly desirable. If supported however, such mechanism(s) MUST be
properly authenticated. properly authenticated.
Means of verifying that the signer configuration is compatible with A means of verifying that the signer configuration is compatible with
the signature policy is also highly desirable. the signature policy is also highly desirable.
Disclosure of a private signature key component to a third party Disclosure of a private signature key component to a third party
allows that third party to impersonate the sender. Protection of allows that third party to impersonate the sender. The protection of
private signature key data is therefore a critical concern. Signers private signature key data is therefore a critical concern. Signers
SHOULD support use of cryptographic hardware providing key management SHOULD support use of cryptographic hardware providing key management
features. features.
The import and export of private keys, and the ability to generate a The import and export of private keys, and the ability to generate a
Certificate Signing Request (CSR) for certificate registration are Certificate Signing Request (CSR) for certificate registration are
highly desirable. highly desirable.
6.1.2. Verifier 2.2. Email Infrastructure Agents
Verifiers SHOULD treat the result of the verification step as an
input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are
known.
In particular, verifiers SHOULD NOT automatically assume that an
email message that does not contain a signature, or that contains a
signature that does not validate, is forged. Verifiers should treat
a signature that fails to validate the same as if no signature were
present.
6.2. Email Infrastructure Agents
It is expected that the most common venue for a DKIM implementation It is expected that the most common venue for a DKIM implementation
will be within the infrastructure of an organization's email service, will be within the infrastructure of an organization's email service,
such as a department or a boundary MTA. such as a department or a boundary MTA.
Outbound: An MSA or Outbound MTA should allow for automatic Outbound: An MSA or Outbound MTA should allow for the automatic
verification of the MTA configuration such that the MTA can verification of the MTA configuration such that the MTA can
generate an operator alert if it determines that it is (1) an generate an operator alert if it determines that it is (1) an
edge MTA, (2) configured to send email messages that do not edge MTA, and (2) configured to send email messages that do not
comply with the published DKIM sending policy. comply with the published DKIM sending policy.
An outbound MTA should be aware that users may employ MUAs that An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to take steps add their own signatures and be prepared to take steps
necessary to ensure that the message sent is in compliance with necessary to ensure that the message sent is in compliance with
the advertised email sending policy. the advertised email sending policy.
Inbound: An inbound MTA or an MDA that does not support DKIM Inbound: An inbound MTA or an MDA that does not support DKIM
should avoid modifying messages in ways that prevent should avoid modifying messages in ways that prevent
verification by other MTAs, or MUAs to which the message may be verification by other MTAs, or MUAs to which the message may be
forwarded. forwarded.
An inbound MTA or an MDA may incorporate an indication of the
verification results into the message, such as using an
Authentication-Results header.
[I-D.kucherawy-sender-auth-header]
Intermediaries: An email intermediary is both an inbound and Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the outbound MTA. Each of the requirements outlined in the
sections relating to MTAs apply. If the intermediary modifies sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary a message in a way that breaks the signature, the intermediary
+ SHOULD deploy abuse filtering measures on the inbound mail, + SHOULD deploy abuse filtering measures on the inbound mail,
and and
+ MAY remove all signatures that will be broken + MAY remove all signatures that will be broken
In addition the intermediary MAY: In addition the intermediary MAY:
* Verify the message signature prior to modification. + Verify the message signature prior to modification.
* Incorporate an indication of the verification results into the + Incorporate an indication of the verification results into
message, such as using an Authentication-Results header the message, such as using an Authentication-Results header.
[I-D.kucherawy-sender-auth-header]. [I-D.kucherawy-sender-auth-header]
* Sign the modified message including the verification results + Sign the modified message including the verification results
(e.g., the Authentication-Results header). (e.g., the Authentication-Results header).
6.3. Filtering 2.3. Filtering
Developers of filtering schemes designed to accept DKIM Developers of filtering schemes designed to accept DKIM
authentication results as input should be aware that their authentication results as input should be aware that their
implementations will be subject to counter-attack by email abusers. implementations will be subject to counter-attack by email abusers.
The efficacy of a filtering scheme cannot therefore be determined by The efficacy of a filtering scheme cannot therefore be determined by
reference to static test vectors alone; resistance to counter attack reference to static test vectors alone; resistance to counter attack
must also be considered. must also be considered.
Naive learning algorithms that only consider the presence or absence Naive learning algorithms that only consider the presence or absence
of a valid DKIM signature are vulnerable to an attack in which a of a verified DKIM signature, without considering more information
spammer or other malefactor signs all their mail, thus creating a about the message, are vulnerable to an attack in which a spammer or
large negative value for presence of a DKIM signature in the hope of other malefactor signs all their mail, thus creating a large negative
discouraging widespread use. value for presence of a DKIM signature in the hope of discouraging
widespread use.
If heuristic algorithms are employed, they should be trained on If heuristic algorithms are employed, they should be trained on
feature sets that sufficiently reveal the internal structure of the feature sets that sufficiently reveal the internal structure of the
DKIM responses. In particular the algorithm should consider the DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature, rather domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not. than the existence of a signature or not.
Unless a scheme can correlate the DKIM signature with accreditation Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of a DKIM signature SHOULD be or reputation data, the presence of a DKIM signature SHOULD be
ignored. ignored.
6.4. DNS Server 2.4. DNS Server
At a minimum, a DNS server that handles queries for DKIM key records At a minimum, a DNS server that handles queries for DKIM key records
must perform server administrators to add free-form TXT records. It must allow the server administrators to add free-form TXT records.
would, of course, be better for provide them with a structured form, It would, of course, be better for provide them with a structured
to support the DKIM-specific fields. form, to support the DKIM-specific fields.
7. Deployment 2.5. Deployment
This section describes the basic steps for introducing DKIM into an This section describes the basic steps for introducing DKIM into an
organization's email service operation. The considerations are organization's email service operation. The considerations are
divided between the generating DKIM signatures (Signing) and the divided between the generating DKIM signatures (Signing) and the
processing of messages that contain a DKIM signature (Verifying). processing of messages that contain a DKIM signature (Verifying).
7.1. Signing 2.5.1. Key Management
Creating messages that have DKIM signatures requires modification of Selectors Selectors are assigned according to the administrative
only two portions of the email service: 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, and not include the selector.
This permits the selector to be used only for key
administration, rather than having an effect on reputation
assessment.
2.5.2. Signing
Creating messages that have DKIM signatures requires a modification
to only two portions of the email service:
o Addition of relevant DNS information. o Addition of relevant DNS information.
o Addition of the signature by a trusted module within the o Addition of the signature by a trusted module within the
organization's email handling service. organization's email handling service.
The signing module uses the appropriate private key to create a The signing module uses the appropriate private key to create a
signature. The means by which the signing module obtains this key is signature. The means by which the signing module obtains the private
not specified by DKIM. Given that DKIM is intended for use during key is not specified by DKIM. Given that DKIM is intended for use
email transit, rather than for long-term storage, it is expected that during email transit, rather than for long-term storage, it is
keys will be changed regularly. Clearly this means that key expected that keys will be changed regularly. Clearly this means
information should not be hard-coded into software. that key information should not be hard-coded into software.
7.1.1. DNS Records 2.5.2.1. DNS Records
A receiver attempting to validate a DKIM signature must obtain the A receiver attempting to verify a DKIM signature must obtain the
public key that is associated with the signature for that message. public key that is associated with the signature for that message.
The DKIM-Signature header in the message will specify the basic The DKIM-Signature header in the message will specify the basic
domain name doing the signing and the selector to be used for the domain name doing the signing and the selector to be used for the
specific public key. Hence, the relevant specific public key. Hence, the relevant
<selector>._domainkeys.<domain-name> DNS record needs to contain a <selector>._domainkey.<domain-name> DNS record needs to contain a
DKIM-related resource record (RR) that provides the public key DKIM-related resource record (RR) that provides the public key
information. information.
The administrator of the zone containing the relevant domain name The administrator of the zone containing the relevant domain name
adds this information. Initial DKIM DNS information is contained adds this information. Initial DKIM DNS information is contained
within TXT RRs. DNS administrative software varies considerably in within TXT RRs. DNS administrative software varies considerably in
its abilities to add new types of DNS records. its abilities to add new types of DNS records.
7.1.2. Signing Module 2.5.2.2. Signing Module
The module doing signing can be placed anywhere within an The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain (ADMD); organization's trusted Administrative Management Domain (ADMD);
common choices are expected to be department-level posting and common choices are expected to be department-level posting and
delivering agents, as well as boundary MTAs to the open Internet. delivering agents, as well as boundary MTAs to the open Internet.
(Note that it is entirely acceptable for MUAs to perform signing and (Note that it is entirely acceptable for MUAs to perform signing and
validation.) Hence the choice among the modules depends upon verification.) Hence the choice among the modules depends upon
software development and administrative overhead tradeoffs. One software development and administrative overhead tradeoffs. One
perspective that helps resolve this choice is the difference between perspective that helps resolve this choice is the difference between
the flexibility of use by systems at (or close to) the MUA, versus the flexibility of use by systems at (or close to) the MUA, versus
the centralized control that is more easily obtained by implementing the centralized control that is more easily obtained by implementing
the mechanism "deeper" into the organization's email infrastructure, the mechanism "deeper" into the organization's email infrastructure,
such as at its boundary MTA. such as at its boundary MTA.
7.1.3. Signing Policies and Practices 2.5.2.3. Signing Policies and Practices
Every organization (ADMD) will have its own policies and practices Every organization (ADMD) will have its own policies and practices
for deciding when to sign messages and with what domain name and key for deciding when to sign messages and with what domain name and key
(selector). Examples include signing all mail, signing mail from (selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub- particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing domains. Given this variability, and the likelihood that signing
practices will change over time, it will be useful to have these practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information, decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software. rather than being more deeply coded into the signing software.
7.2. Verifying 2.5.3. Verifying
2.5.3.1. Verifier
Verifiers SHOULD treat the result of the verification step as an
input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are
known.
In particular, verifiers SHOULD NOT automatically assume that an
email message that does not contain a signature, or that contains a
signature that does not verify, is forged. Verifiers should treat a
signature that fails to verify the same as if no signature were
present.
Verification is performed within an ADMD that wishes to make Verification is performed within an ADMD that wishes to make
assessments based upon the DKIM signature's domain name. Any assessments based upon the DKIM signature's domain name. Any
component within the ADMD that handles messages, whether in transit component within the ADMD that handles messages, whether in transit
or being delivered, can do the verifying and subsequent assessments. or being delivered, can do the verifying and subsequent assessments.
Verification and assessment might occur within the same software Verification and assessment might occur within the same software
mechanism, such as a Boundary MTA, or an MDA. Or they may be mechanism, such as a Boundary MTA, or an MDA. Or they may be
separated, such as having verification performed by the Boundary MTA separated, such as having verification performed by the Boundary MTA
and assessment performed by the MDA. and assessment performed by the MDA.
As with the signing process, choice of service venues for As with the signing process, choice of service venues for
verification and assessment -- such as filtering or presentation to verification and assessment -- such as filtering or presentation to
the recipient user -- depend on trade-offs for flexibility, control, the recipient user -- depend on trade-offs for flexibility, control,
and operational ease. An added concern is that the linkage between and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: the assessment verification and assessment entails essential trust: the assessment
module MUST have a strong basis for believing that the verification module MUST have a strong basis for believing that the verification
information is correct. information is correct.
7.2.1. DNS Client 2.5.3.2. DNS Client
The primary means of publishing DKIM key information, initially, is The primary means of publishing DKIM key information, initially, is
initially through DNS TXT records. Some DNS client software might initially through DNS TXT records. Some DNS client software might
have problems obtaining these records; as DNS client software have problems obtaining these records; as DNS client software
improves this will not be a concern. improves this will not be a concern.
7.2.2. Boundary Enforcement 2.5.3.3. Boundary Enforcement
In order for an assessment module to trust the information it In order for an assessment module to trust the information it
receives about verification (e.g., Authentication-Results headers), receives about verification (e.g., Authentication-Results headers),
it MUST eliminate verification information originating from outside it MUST eliminate verification information originating from outside
the ADMD in which the assessment mechanism operates. As a matter of the ADMD in which the assessment mechanism operates. As a matter of
friendly practice, it is equally important to make sure that friendly practice, it is equally important to make sure that
verification information generated within the ADMD not escape outside verification information generated within the ADMD not escape outside
of it. of it.
In most environments, the easiest way to enforce this is to place In most environments, the easiest way to enforce this is to place
modules in the receiving and sending Boundary MTA(s) that strip any modules in the receiving and sending Boundary MTA(s) that strip any
existing verification information. existing verification information.
7.3. Mail User Agent 2.5.4. Mail User Agent
DKIM is designed to support deployment and use in email components DKIM is designed to support deployment and use in email components
other than an MUA. However an MUA MAY also implement DKIM features other than an MUA. However an MUA MAY also implement DKIM features
directly. directly.
Outbound: If an MUA is configured to send email directly, rather Outbound: If an MUA is configured to send email directly, rather
than relayed through an outbound MSA, the MUA SHOULD be than relayed through an outbound MSA, the MUA SHOULD be
considered as if it were an outbound MTA for the purposes of considered as if it were an outbound MTA for the purposes of
DKIM. An MUA MAY support signing even if mail is to be relayed DKIM. An MUA MAY support signing even if mail is to be relayed
through an outbound MSA. In this case the signature applied by through an outbound MSA. In this case the signature applied by
the MUA may be in addition to any MSA signature. the MUA may be in addition to any MSA signature.
Inbound: An MUA MAY rely on a report of a DKIM signature Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA verification that took place at some point in the inbound MTA
path (e.g., an Authentication-Results header), or an MUA MAY path (e.g., an Authentication-Results header), or an MUA MAY
perform DKIM signature verification directly. A verifying MUA perform DKIM signature verification directly. A verifying MUA
SHOULD allow for the case where mail is modified in the inbound SHOULD allow for the case where mail is modified in the inbound
MTA path. MTA path.
7.4. Transition strategy 2.5.5. Transition strategy
Deployment of a new signature algorithm without a 'flag day' requires Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that signers and verifiers can phase in a transition strategy such that signers and verifiers can phase in
support for the new algorithm independently, and (if necessary) phase support for the new algorithm independently, and (if necessary) phase
out support for the old algorithm independently. out support for the old algorithm independently.
[Note: this section assumes that a security policy mechanism exists. [Note: this section assumes that a security policy mechanism exists.
It is subject to change.] It is subject to change.]
DKIM achieves these requirements through two features: First a signed DKIM achieves these requirements through two features: First a signed
message may contain multiple signatures created by the same signer. message may contain multiple signatures created by the same signer.
Secondly the security policy layer allows the signing algorithms in Secondly the security policy layer allows the signing algorithms in
use to be advertised, thus preventing a downgrade attack. use to be advertised, thus preventing a downgrade attack.
7.4.1. Signer transition strategy 2.5.5.1. Signer transition strategy
Let the old signing algorithm be A, the new signing algorithm be B. Let the old signing algorithm be A, the new signing algorithm be B.
The sequence of events by which a Signer may introduce the new The sequence of events by which a Signer may introduce the new
signing algorithm B, without disruption of service to legacy signing algorithm B, without disruption of service to legacy
verifiers, is as follows: verifiers, is as follows:
1. Signer signs with algorithm A 1. Signer signs with algorithm A
A. Signer advertises that it signs with algorithm A A. Signer advertises that it signs with algorithm A
skipping to change at page 26, line 45 skipping to change at page 23, line 5
4. Signer determines that support for algorithm A is to be withdrawn 4. Signer determines that support for algorithm A is to be withdrawn
A. Signer removes advertisement for Algorithm A A. Signer removes advertisement for Algorithm A
B. Signer waits for cached copies of earlier signature policy to B. Signer waits for cached copies of earlier signature policy to
expire expire
C. Signer stops signing with Algorithm A C. Signer stops signing with Algorithm A
7.4.2. Verifier transition strategy 2.5.5.2. Verifier transition strategy
The actions of the verifier are independent of the signer's actions The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm A to be upgraded to support algorithm B without requiring algorithm A to be
withdrawn. The decisions of the verifier must make are therefore: withdrawn. The decisions of the verifier must make are therefore:
o The verifier MAY change the degree of confidence associated with o The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given any signature at any time, including determining that a given
skipping to change at page 27, line 28 skipping to change at page 23, line 36
* In this case the verifier would ignore signatures created using * In this case the verifier would ignore signatures created using
algorithm A and references to algorithm A in policy records algorithm A and references to algorithm A in policy records
would be treated as if the algorithm were not implemented. would be treated as if the algorithm were not implemented.
o The verifier MAY decide to add support for additional signature o The verifier MAY decide to add support for additional signature
algorithms at any time. algorithms at any time.
* The verifier MAY add support for algorithm B at any time. * The verifier MAY add support for algorithm B at any time.
8. On-going Operations 2.5.6. Migrating from DomainKeys
2.5.6.1. Signing
DNS Records: DKIM is upwardly compatible with existing
DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module
does not automatically require additional DNS administration!
However DKIM has enhanced the DomainKeys DNS key record format
by adding several additional optional parameters.
Boundary MTA: The principle use of DomainKeys is at Boundary
MTAs. Because no operational transition is ever instantaneous,
it is not adviseable for existing DomainKeys signers to switch
to DKIM without continuing to perform DomainKeys signing. A
signer should add a DKIM signature to a message that also has a
DomainKeys signature, until such time as DomainKeys receive-
side support is sufficiently reduced. With respect to signing
policies, a reasonable, initial approach is to use DKIM
signatures in the same way as DomainKeys signatures are already
being used.
2.5.6.2. Verifying
DNS Client: DNS queries for the DKIM key record, use the same
Domain Name naming conventions as were used for DomainKeys, and
the same basic record format. No changes to the DNS client
should be required.
Verifying module: See the section on Signing above.
2.6. On-going Operations
This section describes the basic steps for operation of email systems This section describes the basic steps for operation of email systems
that use DKIM, after the capability has initially been deployed. The that use DKIM, after the capability has initially been deployed. The
primary considerations are: primary considerations are:
o the upkeep of the selector files, and o the upkeep of the selector files, and
o the security of the private keys. o the security of the private keys.
8.1. DNS Signature Record Deployment Considerations 2.6.1. DNS Signature Record Installation Considerations
Even with use of the DNS, one challenge is that DNS record management
is usually operated by an administrative staff that is different from
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.
The key point to remember is that the DNS DKIM selectors WILL and The key point to remember is that the DNS DKIM selectors WILL and
SHOULD be changed over time. Some reasons for changing DKIM SHOULD be changed over time. Some reasons for changing DKIM
selectors are well understood; others are still theoretical. There selectors are well understood, while others are still theoretical.
are several schemes that may be used to determine the policies for There are several schemes that may be used to determine the policies
changing DKIM selectors: for changing DKIM selectors:
o time based o time based
o associations with clusters of servers o associations with clusters of servers
o the use of third party signers
o the use of third party signers
o security considerations o security considerations
8.1.1. Time Basis and Security Considerations 2.6.1.1. Time Basis and Security Considerations
The reason for changing the selector periodically is usually related The reason for changing the selector periodically is usually related
to the security exposure of a system. When the potential exposure of to the security exposure of a system. When the potential exposure of
the private keys associated with the DKIM selector have reached the private keys associated with the DKIM selector have reached
sufficient levels, the selector should be changed. (It is unclear sufficient levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in deciding when currently what kinds of metrics can be used to aid in deciding when
the exposure has reached sufficient levels to warrant changing the the exposure has reached sufficient levels to warrant changing the
selector.) selector.)
For example, For example,
skipping to change at page 28, line 39 skipping to change at page 25, line 37
o While the use of DKIM information is transient, keys with o While the use of DKIM information is transient, keys with
sufficient exposure do become stale and should be changed. sufficient exposure do become stale and should be changed.
o Whenever you make a substantial system change, such as bringing up o Whenever you make a substantial system change, such as bringing up
a new server, or making a major operating system change, you a new server, or making a major operating system change, you
should consider changing the selector. should consider changing the selector.
o Whenever there is either suspicion or evidence of the compromise o Whenever there is either suspicion or evidence of the compromise
of the system or the private keys, you should change the selector. of the system or the private keys, you should change the selector.
8.1.2. Deploying New Selectors 2.6.1.2. Deploying New Selectors
A primary consideration in changing the selector is remembering to A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. If they are separate, both Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new the mail team and the DNS team will be involved in deploying new
selectors. selectors.
When deploying a new selector, it needs to be phased in: When deploying a new selector, it needs to be phased in:
1. generate the new public / private key pair and create a selector 1. Generate the new public / private key pair and create a new
record with the public key in it selector record with the public key in it.
2. add the new selector record to your DNS
3. verify that the new selector record can be used to verify 2. Add the new selector record to your DNS.
signatures
4. turn on signing with the new private key 3. Verify that the new selector record can be used to verify
signatures.
5. remove the old private key from your servers 4. Turn on signing with the new private key.
6. after a period of time, remove the old selector from your DNS 5. Remove the old private key from your servers.
6. After a period of time, remove the old selector from your DNS.
The time an unused selector should be kept in the DNS system is 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 dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable. immediately. Otherwise, longer periods are allowable.
8.1.3. Subdomain Considerations 2.6.1.3. Subdomain Considerations
A Domain Name is the basis for making differential quality A Domain Name is the basis for making differential quality
assessments about a DKIM-signed message. It is reasonable for a assessments about a DKIM-signed message. It is reasonable for a
single organization to have a variety of very different activities, single organization to have a variety of very different activities,
which warrant a variety of very different assessments. A convenient which warrant a variety of very different assessments. A convenient
way to distinguish among such activities is to sign with different way to distinguish among such activities is to sign with different
domain names. That is, the organization should sign with sub-domain domain names. That is, the organization should sign with sub-domain
names that are used for different organizational activities. names that are used for different organizational activities.
8.1.4. Third party Signature Delegations 2.6.1.4. Third party Signature Delegations
Allowing third parties to sign email from your domain opens your Allowing third parties to sign email from your domain opens your
system security to include the security of the third party's systems. 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 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 selector and private key as your main mail system. It is recommended
that each third party be given their own private key and selector. that each third party be given their own private key and selector.
This limits the exposure for any given private key, and minimizes the This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed. impact if any given private key were exposed.
8.2. Private Key Management 2.6.2. Private Key Management
The permissions of private key files must be carefully managed. If The permissions of private key files must be carefully managed. If
key management hardware support is available, it should be used. key management hardware support is available, it should be used.
Auditing software should be used to periodically verify that the Auditing software should be used to periodically verify that the
permissions on the private key files remain secure. [ Expand this permissions on the private key files remain secure.
section? ]
8.3. Mailing list manager developers 2.6.3. Mailing list manager developers
A mailing list often provides facilities to its administrator to A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that flow through the list. manipulate parts of the mail messages that flow through the list.
The desired goal is that messages flowing through the mailing list The desired goal is that messages flowing through the mailing list
will be verifiable by the recipient as being from the list, or will be verifiable by the recipient as being from the list, or
failing that, as being from the individual list members. failing that, as being from the individual list members.
In most cases, the list and/or its mail host SHOULD add its own DKIM In most cases, the list and/or its mail host SHOULD add its own DKIM
signature to list mail. This could be done in the list management signature to list mail. This could be done in the list management
software, in an outgoing MSA or MTA, or both. List management software, in an outgoing MSA or MTA, or both. List management
software often makes modifications to messages that will break software often makes modifications to messages that will break
incoming signatures, such as adding subject tags, adding message incoming signatures, such as adding subject tags, adding message
headers or footers, and adding, deleting, or reordering MIME parts. headers or footers, and adding, deleting, or reordering MIME parts.
skipping to change at page 30, line 16 skipping to change at page 27, line 12
will be verifiable by the recipient as being from the list, or will be verifiable by the recipient as being from the list, or
failing that, as being from the individual list members. failing that, as being from the individual list members.
In most cases, the list and/or its mail host SHOULD add its own DKIM In most cases, the list and/or its mail host SHOULD add its own DKIM
signature to list mail. This could be done in the list management signature to list mail. This could be done in the list management
software, in an outgoing MSA or MTA, or both. List management software, in an outgoing MSA or MTA, or both. List management
software often makes modifications to messages that will break software often makes modifications to messages that will break
incoming signatures, such as adding subject tags, adding message incoming signatures, such as adding subject tags, adding message
headers or footers, and adding, deleting, or reordering MIME parts. headers or footers, and adding, deleting, or reordering MIME parts.
By adding its own signature after these modifications, the list By adding its own signature after these modifications, the list
provides a valid recognizable signature for list recipients. provides a verifiable, recognizable signature for list recipients.
In some cases, mailing list software is simple enough that signatures In some cases, the modifications made by the mailing list software
on incoming messages will still be valid after being remailed by the are simple enough that signatures on incoming messages will still be
list. It is still preferable that the list sign its mail so that verifiable after being remailed by the list. It is still preferable
recipients can distinguish mail sent through the list from mail sent that the list sign its mail so that recipients can distinguish
directly by list members, but in the absence of a list signature, a between mail sent through the list and mail sent directly to a list
recipient may be able to recognize and use the signatures of list member. In the absence of a list signature, a recipient may still be
members known to the recipient. able to recognize and use the original signatures of the list
members.
9. Example Uses 2.7. Example Uses
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 history Combining this information with information that allows the history
of the domain name owner to be assessed may allow processing the of the domain name owner to be assessed may allow processing the
message, based on the probability that the message is likely to be message, based on the probability that the message is likely to be
trustworthy, or not, without the need for heuristic content analysis. trustworthy, or not, without the need for heuristic content analysis.
9.1. Protection of Internal Mail 2.7.1. Protection of Internal Mail
One identity is particularly amenable to easy and accurate One identity is particularly amenable to easy and accurate
assessment: The organization's own identity! Members of an assessment: The organization's own identity. Members of an
organization tend to trust messages that purport to be from within organization tend to trust messages that purport to be from within
that organization. However Internet Mail does not provide a that organization. However Internet Mail does not provide a
straightforward means of determining whether such mail is, in fact, straightforward means of determining whether such mail is, in fact,
from within the organization. DKIM can be used to remedy this from within the organization. DKIM can be used to remedy this
exposure. If the organization signs all of its mail, then its exposure. If the organization signs all of its mail, then its
boundary MTAs can look for mail purporting to be from the boundary MTAs can look for mail purporting to be from the
organization but which does not contain a valid signature. Such mail organization but does not contain a verifiable signature. Such mail
can be presumed to be spurious. can be presumed to be spurious.
9.2. Recipient-based Assessments 2.7.2. Recipient-based Assessments
Recipients of large volumes of email can generate reputation data for Recipients of large volumes of email can internally generate
email senders internally. Recipients of smaller volumes of messages reputation data for email senders. Recipients of smaller volumes of
are likely to need to acquire reputation data from a third party. In messages are likely to need to acquire reputation data from a third
either case the use of reputation data is intrinsically limited to party. In either case the use of reputation data is intrinsically
email senders that have established a prior history of sending limited to email senders that have established a prior history of
messages. sending messages.
In fact, an email receiving service may be in a position to establish In fact, an email receiving service may be in a position to establish
bilateral agreements with particular senders, such as business bilateral agreements with particular senders, such as business
partners or trusted bulk sending services. Although it is not partners or trusted bulk sending services. Although it is not
practical for each recipient to accredit every sender, definition of practical for each recipient to accredit every sender, the definition
core networks of explicit trust can be quite useful. of core networks of explicit trust can be quite useful.
9.2.1. Third-party Assessments 2.7.2.1. Third-party Assessments
For scaling efficiency, it is appealing to have Trusted Third Party For scaling efficiency, it is appealing to have Trusted Third Party
assessment services, to allow an email sender to obtain a single assessment services, to allow an email sender to obtain a single
assessment that is then recognized by every email recipient that assessment that is then recognized by every email recipient that
recognizes the Trusted Third Party. recognizes the Trusted Third Party.
9.3. DKIM Support in the Client 2.7.3. DKIM Support in the Client
The DKIM specification is expected to be used primarily between The DKIM specification is expected to be used primarily between
Boundary MTAs, or other infrastructure components of the originating Boundary MTAs, or other infrastructure components of the originating
and receiving ADMDs. However there is nothing in DKIM that is and receiving ADMDs. However there is nothing in DKIM that is
specific to those venues. In particular, it should be possible to specific to those venues. In particular, it should be possible to
support signing and validating in MUAs. support signing and verifying in MUAs.
However, it is comment for components of an ADMD's email However, it is common for components of an ADMD's email
infrastructure to do violence to message, so as to render a DKIM infrastructure to do violence to a message, such as to render a DKIM
signature invalid. Hence, users of MUAs that support DKIM signing signature invalid. Hence, users of MUAs that support DKIM signing
and/or validating need a basis for knowing that their associated and/or verifying need a basis for knowing that their associated email
email infrastructure will maintain signature validity. infrastructure will not break a signature.
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 not result in a less than satisfactory verification of a signature not result in a less than satisfactory
user experience compared to leaving the message unsigned. user experience compared to leaving the message unsigned.
9.4. Per user signature 2.7.4. Per user signatures
Although DKIM's use of domain names is optimized for a scope of Although DKIM's use of domain names is optimized for a scope of
organization-level signing, it is possible to have sub-domains and/or organization-level signing, it is possible to administer sub-domains
selectors be administered in a way that supports per-user signing. and/or selectors in a way that supports per-user signing.
NOTE: As stated earlier, it is important to distinguish between use NOTE: As stated earlier, it is important to distinguish between the
of selectors, for differential administration of keys, versus sub- use of selectors for differential administration of keys, versus
domains, for differential reputations. the use of sub-domains for differential reputations.
As a constraint on an authorized DKIM signing agent, their associated As a constraint on an authorized DKIM signing agent, their associated
key record can specify restrictions on the email addresses permitted key record can specify restrictions on the email addresses permitted
to be signed with that domain and key. A typical intent of this to be signed with that domain and key. A typical intent of this
feature is to allow a company to delegate the signing authority for feature is to allow a company to delegate the signing authority for
bulk marketing communications without the risk of effectively bulk marketing communications without the risk of effectively
delegating the authority to sign messages purporting to come from the delegating the authority to sign messages purporting to come from the
domain-owning organization's CEO. domain-owning organization's CEO.
NOTE: Any scheme that involves maintenance of a significant number NOTE: Any scheme that involves maintenance of a significant number
of public keys is likely to require infrastructure enhancements, of public keys is likely to require infrastructure enhancements,
to support that management. For example, a system in which the to support that management. For example, a system in which the
end user is required to generate a public key pair and transmit it end user is required to generate a public key pair and transmit it
to the DNS administrator out of band is not likely to meet to the DNS administrator out of band is not likely to meet
acceptance criteria for either usability or security. acceptance criteria for either usability or security.
10. Acknowledgements 3. Acknowledgements
TBD TBD
11. { Misc Text -- Should go elsewhere, if used at all } 4. Informative References
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".
MUA UI considerations
key delegation/ 3rd party
12. Informative References
[I-D.delany-domainkeys-base]
Delany, M., "Domain-based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)",
draft-delany-domainkeys-base-06 (work in progress),
July 2006.
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-10 (work in progress),
February 2007.
[I-D.ietf-dkim-threats] [I-D.ietf-openpgp-rfc2440bis]
Fenton, J., "Analysis of Threats Motivating DomainKeys Callas, J., "OpenPGP Message Format",
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work draft-ietf-openpgp-rfc2440bis-22 (work in progress),
in progress), May 2006. April 2007.
[I-D.kucherawy-sender-auth-header] [I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header for Indicating Sender Kucherawy, M., "Message Header for Indicating Sender
Authentication Status", Authentication Status",
draft-kucherawy-sender-auth-header-04 (work in progress), draft-kucherawy-sender-auth-header-04 (work in progress),
February 2007. February 2007.
[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.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 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.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001. "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
May 2007.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
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
 End of changes. 160 change blocks. 
763 lines changed or deleted 639 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/