draft-ietf-dkim-deployment-02.txt   draft-ietf-dkim-deployment-03.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational P. Hallam-Baker Intended status: Informational E. Siegel
Expires: May 7, 2009 VeriSign Inc. Expires: August 13, 2009 Constant Contact, Inc.
P. Hallam-Baker
VeriSign Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
E. Siegel February 9, 2009
Constant Contact, Inc.
November 3, 2008
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-02 draft-ietf-dkim-deployment-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 7, 2009. This Internet-Draft will expire on August 13, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
DomainKeys Identified Mail (DKIM) allows an organization to take DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. The organization can be the author's, the validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. A originating sending site, an intermediary, or one of their agents. A
message can contain multiple signatures, from the same or different message can contain multiple signatures, from the same or different
organizations involved with the message. DKIM defines a domain-level organizations involved with the message. DKIM defines a domain-level
digital signature authentication framework for email, using public digital signature authentication framework for email, using public
key cryptography, using the domain name service as its key server key cryptography, using the domain name service as its key server
technology [RFC4871]. This permits verification of a responsible technology [RFC4871]. This permits verification of a responsible
organization, as well as the integrity of the message contents. DKIM organization, as well as the integrity of the message contents. DKIM
will also provide a mechanism that permits potential email signers to will also provide a mechanism that permits potential email signers to
publish information about their email signing practices; this will publish information about their email signing practices; this will
permit email receivers to make additional assessments about messages. permit email receivers to make additional assessments about messages.
DKIM's authentication of email identity can assist in the global DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing. This document provides control of "spam" and "phishing". This document provides
implementation, deployment, operational and migration considerations implementation, deployment, operational and migration considerations
for DKIM. for DKIM.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Key Generation, Storage, and Management . . . . . . . . . . . 3 2. Using DKIM as Part of Trust Assessment . . . . . . . . . . . . 5
2.1. General Coding Criteria for Cryptographic Applications . . 3 2.1. A Systems View of Email Trust Assessment . . . . . . . . . 5
2.2. Key Generation and Storage . . . . . . . . . . . . . . . . 4 2.2. Choosing a DKIM Tag for the Assessment Identifier . . . . 7
2.3. DNS Signature Record Deployment and Maintenance 2.3. Choosing the Signing Domain Name . . . . . . . . . . . . . 9
Considerations . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11
3. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 8 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 14
3.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Private Key Management: Deployment and Ongoing
3.3. Signature Transition Strategy . . . . . . . . . . . . . . 12 Operations . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Storing Public Keys: DNS Server Software Considerations . 16
4.1. Verifier . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Per User Signing Key Management Issues . . . . . . . . . . 17
4.2. DNS Client . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Third Party Signer Key Management and Selector
4.3. Boundary Enforcement . . . . . . . . . . . . . . . . . . . 15 Administration . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Filtering Software . . . . . . . . . . . . . . . . . . . . 15 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18
5. DKIM Deployment Considerations for Email Agents . . . . . . . 15 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Email Infrastructure Agents . . . . . . . . . . . . . . . 15 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 17 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20
6. Migrating from DomainKeys . . . . . . . . . . . . . . . . . . 17 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 20
6.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 21
7. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 21
7.1. Protection of Internal Mail . . . . . . . . . . . . . . . 18 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 22
7.2. Recipient-based Assessments . . . . . . . . . . . . . . . 19 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 23
7.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 19 6.4. Using Trusted 3rd Party Senders . . . . . . . . . . . . . 24
7.4. Per user signatures . . . . . . . . . . . . . . . . . . . 19 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Author's Organization - Differentiated Types of Mail . . . 27
11. Informative References . . . . . . . . . . . . . . . . . . . . 20 7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Author Domain Signing Practices . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 23 7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 28
7.6. Independent Third Party Service Providers . . . . . . . . 28
7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 29
7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 29
8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. Non-standard Submission and Delivery Scenarios . . . . . . 30
8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 31
8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 31
8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 32
8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 34
9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 35
9.1. Security Considerations . . . . . . . . . . . . . . . . . 35
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
11. Informative References . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 37
A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. General Coding Criteria for Cryptographic
Applications . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
There are many areas to be considered when deploying DomainKeys DomainKeys Identified Mail (DKIM) allows an organization to claim
Identified Mail (DKIM). This document provides practical tips for: responsibility for transmitting a message, in a way that can be
validated by a recipient. This document provides practical tips for:
those who are developing DKIM software, mailing list managers, those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing DNS servers; those who are deploying DKIM software, keys, mailing
list software, and migrating from DomainKeys; and those who are list software, and migrating from DomainKeys; and those who are
responsible for the on-going operations of an email infrastructure responsible for the on-going operations of an email infrastructure
that has deployed DKIM. that has deployed DKIM.
The document is organized aorund the key concepts related to DKIM. The document is organized around the key concepts related to DKIM.
Within each section, additional considerations specific to Within each section, additional considerations specific to
development, deployment, or ongoing operations are highlighted where development, deployment, or ongoing operations are highlighted where
appropriate. appropriate.
[[anchor2: maybe this is a good place to mention the possibility of [[anchor2: MSK: maybe this is a good place to mention the possibility
collecting verification history for selectors domains as a means of of collecting verification history for selectors domains as a means
observing over time behaviour of signers for the purpose of asserting of observing over time behaviour of signers for the purpose of
local reputation]] asserting local reputation]]
2. Key Generation, Storage, and Management 2. Using DKIM as Part of Trust Assessment
DKIM defines a domain-level digital signature authentication 2.1. A Systems View of Email Trust Assessment
framework for email, using public key cryptography, using the domain
name service as its key server technology [RFC4871]. This section
covers considerations around generating, deploying, and managing the
public and private keys required for DKIM to function.
2.1. General Coding Criteria for Cryptographic Applications DKIM participates in a trust-oriented enhancement to the Internet's
email service, to facilitate message handling decisions, such as for
delivery and for content display. Trust-oriented message handling
has substantial differences from approaches that consider messages in
terms of risk and abuse. With trust, there is a collaborative
exchange between a willing participant along the sending path and a
willing participant at the recipient site. In contrast, the risk
model entails independent action by the recipient site, in the face
of a potentially unknown, hostile and deceptive sender. This
translates into a very basic technical difference: In the face of
unilateral action by the recipient and even antagonistic efforts by
the sender, risk-oriented mechanisms must be based on heuristics,
that is, on guessing. Guessing produces statistical results with
some false negatives and some false positives. For trust-based
exchanges, the goal is the deterministic exchange of information.
For DKIM, that information is the one identifier that represents a
stream of mail for which an independent assessment is sought (by the
signer.)
NOTE: This section could possibly be changed into a reference to A trust-based service is built upon a validated Responsible
something else, such as another rfc. Identifier that labels a stream of mail and is controlled by an
identity (role, person or organization.) The identity is
acknowledging some degree of responsibility for the message stream.
Given a basis for believing that an identifier is being used in an
authorized manner, the recipient site can make and use an assessment
of the associated identity. An identity can use different
identifiers, on the assumption that the different streams might
produce different assessments. For example, even the best-run
marketing campaigns will tend to produce some complaints that can
affect the reputation of the associated identifier. Whereas a stream
of transactional messages is likely to have a more pristine
reputation.
Correct implementation of a cryptographic algorithm is a necessary Determining that the identifier's use is valid is quite different
but not a sufficient condition for the coding of cryptographic from determining that the content of a message is valid. The former
applications. Coding of cryptographic libraries requires close means only that the identifier for the responsible role, person or
attention to security considerations that are unique to cryptographic organization has been legitimately associated with a message. The
applications. latter means that the content of the message can be believed and,
typically, that the claimed author of the content is correct. DKIM
validates only the presence of the identifier used to sign the
message. Even when this identifier is validated, DKIM carries no
implication that any of the message content, including the
RFC5322.From field, is valid. Surprisingly, this limit to the
semantics of a DKIM signature applies even when the validated signing
identifier is the same domain name as is used in the From: field!
DKIM's only claim about message content is that the content cited in
the DKIM-Signature: field's h= tag have been delivered without
modification. That is, it asserts message content integrity, not
message content validity.
In addition to the usual security coding considerations, such as As shown in Figure 1, this enhancement is a communication between a
avoiding buffer or integer overflow and underflow, implementers responsible role, person or organization that signs the message and a
should pay close attention to management of cryptographic private recipient organization that assesses its trust in the signer and then
keys and session keys, ensuring that these are correctly initialized makes handling decisions based on a collection of assessments, of
and disposed of. which the DKIM mechanism is only a part. In this model, validation
is an intermediary step, having the sole task of passing a validated
Responsible Identifier to the Identity Assessor. The communication
is of a single Responsible Identifier that the Responsible Identity
wishes to have used by the Identity Assessor. The Identifier is the
sole, formal input and output value of DKIM signing. The Identity
Assessor uses this single, provided Identifier for consulting
whatever assessment data bases are deemed appropriate by the
assessing entity. In turn, output from the Identity Assessor is fed
into a Handling Filter engine that considers a range of factors,
along with this single output value; the range of factors can include
ancillary information from the DKIM validation.
Operating system mechanisms that permit the confidentiality of Identity Assessment covers a range of possible functions. It can be
private keys to be protected against other processes should be used as simple as determining whether the identifier is a member of some
when available. In particular, great care must be taken when list, such as authorized operators or participants in a group that
releasing memory pages to the operating system to ensure that private might be of interest for recipient assessment. Equally, it can
key information is not disclosed to other processes. indicate a degree of trust (reputation) that is to be afforded the
actor using that identifier. The extent to which the assessment
affects handling of the message is, of course, determined later, by
the Handling Filter.
Certain implementations of public key algorithms such as RSA may be +------+------+ +------+------+
vulnerable to a timing analysis attack. | Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| . . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . . . +-------------+ | | | +-------------+
| | Identifier | | Identifier +--|--+ +--+ Assessment |
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-------------+
| DKIM Service |
+-----------------------------------------------+
Support for cryptographic hardware providing key management Figure 1: Actors in a Trust Sequence using DKIM
capabilities is strongly encouraged. In addition to offering
performance benefits, many cryptographic hardware devices provide
robust and verifiable management of private keys.
Fortunately appropriately designed and coded cryptographic libraries 2.2. Choosing a DKIM Tag for the Assessment Identifier
are available for most operating system platforms under license terms
compatible with commercial, open source and free software license
terms. Use of standard cryptographic libraries is strongly
encouraged. These have been extensively tested, reduce development
time and support a wide range of cryptographic hardware.
2.2. Key Generation and Storage The signer of a message needs to be able to provide precise data and
know what that data will mean upon delivery to the Assessor. If
there is ambiguity in the choice that will be made on the receive
side, then the sender cannot know what basis for assessment will be
used. DKIM has three values that specify identification information
and it is easy to confuse their use, although only one defines the
formal input and output of DKIM, with the other two being used for
internal protocol functioning and adjunct purposes, such as auditing
and debugging.
2.2.1. Assignment of Selectors The salient values include the s=, d= and i= parameters in the DKIM-
Signature: header field. In order to achieve the end-to-end
determinism needed for this collaborative exchange from the signer to
the assessor, the core model needs to specify that the signer MUST
provide the assessor with a single, opaque value that the signer
wishes to have used for assessment. This value MUST be the basis for
DKIM-based assessment. The signer MAY provide the assessor with a
second, opaque value that MAY be used when reporting problems with
the end-to-end DKIM process and MAY be used for additional analysis,
such as by the higher-level Handling Filter. These values are
opaque, in that any internal semantics are known only to the signer
and MUST NOT be assumed by the Assessor, within the confines of
DKIM's formal signing specification. Assessment MUST use a value as
a single, complete and uninterpreted string.
Selectors Selectors are assigned according to the administrative The single, mandatory value that DKIM supplies as its output is:
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 d= This specifies the "domain of the signing entity." It is a
domain name and is combined with the Selector to form a DNS
query.
widget.promotion._domainkey.example.com The adjunct values are:
NOTE: It is intended that assessments of DKIM identities be based s= This tag specifies the Selector. It is used to discriminate
on the domain name, and not include the selector. This permits among different keys that can be used for the same d= domain
the selector to be used only for key administration, rather than name. As discussed in Section 4.3 of [I-D.ietf-dkim-overview]:
having an effect on reputation assessment. "If verifiers were to employ the selector as part of a name
assessment mechanism, then there would be no remaining
mechanism for making a transition from an old, or compromised,
key to a new one." Consequently, the Selector is not
appropriate for use as part or all of the identifier used to
make assessments.
[[anchor7: The reputation of a selector could become relevant if i= This tag is optional and provides the "[i]dentity of the
it is known to have "gone rogue" before the DNS owner has a chance user or agent (e.g., a mailing list manager) on behalf of which
to published a new zone update which contains a revoked key.]] this message is signed." The identity can be in the syntax of
an entire email address or only a domain name. The domain name
can be the same as for d= or it can be a sub-name of the d=
name.
2.2.2. Third Party Key Management NOTE: Although the i= identity has the syntax of an email
address, it is not required to have that semantics. That is,
"the identity of the user" need not be the same as the user's
mailbox. For example the signer might wish to use i= to encode
user-related audit information, such as how they were accessing
the service at the time of message posting. Therefore it is
not possible to conclude anything from the i= string's
(dis)similarity to email addresses elsewhere in the header
???????????????? So, i= can have any of these properties:
[[anchor9: what are we trying to cover here? The case where a 3rd * Be a valid domain when it is the same as d=
party generates keys and provides the public key to the domain owner
to publish? Or the case where the domain owner generates keys and
provides the private key to the third party? Either way, I think we
need some discussion of 1st vs. 3rd party (preferably that the
distinction has little relevance except in the presence of ADSP,
since otherwise the reputation of the signing domain and not the 1st
or 3rd party nature of it is what is relevant.]]
3rd party generates the public / private key pair and sends the * Appear to be a sub-domain of d= but might not even exist
public key to be published in the DNS.
2.2.3. Storing Public Keys: DNS Server Software Considerations * Look like a mailbox address but might have different semantics
and therefore not function as a valid email address
* Be unique for each message, such as indicating access details
of the user for the specific posting
This underscores why the tag needs to be treated as being opaque,
since it can represent any semantics, known only to the signer.
Hence, i= serves well as a token that is usable like an Web cookie,
for return to the signing ADMD -- such as for auditing and debugging.
Of course in some scenarios the i= string might provide a useful
adjunct value for additional (heuristic) processing by the Handling
Filter.
2.3. Choosing the Signing Domain Name
A DKIM signing entity can serve different roles, such as author of
content, versus operator of the mail service, versus operator of a
reputation service. In these different roles, the basis for
distinguishing among portions of email traffic can vary. For an
entity creating DKIM signatures it is likely that different portions
of their mail will warrant different levels of trust. For example:
* Mail is sent for different purposes, such as marketing vs.
transactional, and recipients demonstrate different patterns of
acceptance between these.
* For an operator of an email service, there often are distinct
sub-populations of users warranting different levels of trust
or privilege, such as paid vs. free users, or users engaged in
direct correspondence vs. users sending bulk mail.
* Mail originating outside an operator's system, such as when it
is redistributed by a mailing list service run by the operator,
will warrant a different reputation from mail submitted by
users authenticated with the operator.
It is therefore likely to be useful for a signer to use different d=
sub-domain names, for different message traffic streams, so that
receivers can make differential assessments. However, too much
differentiation -- that is, too fine a granularity of signing domains
-- makes it difficult for the receiver to discern a sufficiently
stable pattern of traffic for developing an accurate and reliable
assessment. So the differentiation needs to achieve a balance.
Generally in a trust system, legitimate signers have an incentive to
pick a small stable set of identities, so that recipients and others
can attribute reputations to them. The set of these identities a
receiver trusts is likely to be quite a bit smaller than the set it
views as risky.
The challenge in using additional layers of sub-domains is whether
the extra granularity will be useful for the assessor. In fact,
potentially excessive levels invites ambiguity: if the assessor does
not take advantage of the added granularity, then what granularity
will it use? That ambiguity would move the use of DKIM back to the
realm of heuristics, rather than the deterministic processing that is
its goal.
Hence the challenge is to determine a useful scheme for labeling
different traffic streams. The most obvious choices are among
different types of content and/or different types of authors.
Although stability is essential, it is likely that the choices will
change, over time, so the scheme needs to be flexible.
For those originating message content, the most likely choice of sub-
domain naming scheme will by based upon type of content, which can
use content-oriented labels or service-oriented labels. For example:
transaction.example.com
newsletter.example.com
bugreport.example.com
support.example.com
sales.example.com
marketing.example.com
where the choices are best dictated by whether they provide the
Identity Assessor with the ability to discriminate usefully among
streams of mail that demonstrate significantly different degrees of
recipient acceptance or safety. Again, the danger in providing too
fine a granularity is that related message streams that are labeled
separately will not benefit from an aggregate reputation.
For those operating messaging services on behalf of a variety of
customers, an obvious scheme to use has a different sub-domain label
for each customer. For example:
widgetco.example.net
moviestudio.example.net
bigbank.example.net
However it can also be appropriate to label by the class of service
or class of customer, such as:
premier.example.net
free.example.net
certified.example.net
Prior to using domain names for distinguishing among sources of data,
IP Addresses have been the basis for distinction. Service operators
typically have done this by dedicating specific outbound IP Addresses
to specific mail streams -- typically to specific customers. For
example, a university might want to distinguish mail from the
Administration, versus mail from the student dorms. In order to make
adoption of a DKIM-based service easier, it can be reasonable to
translate the same partitioning of traffic, using domain names in
place of the different IP Addresses.
2.4. Recipient-based Assessments
DKIM gives the recipient site's Identity Assessor a verifiable
identifier to use for analysis. Although the mechanism does not make
claims that the signer is a Good Actor or a Bad Actor, it does make
it possible to know that use of the identifier is valid. This is in
marked contrast with schemes that do not have authentication.
Without verification, it is not possible to know whether the
identifier -- whether taken from the RFC5322.From field,
RFC5321.MailFrom command, or the like -- is being used by an
authorized agent. DKIM solves this problem. Hence with DKIM, the
Assessor can know that two messages with the same DKIM d= identifier
are, in fact, signed by the same person or organization. This
permits a far more stable and accurate assessment of mail traffic
using that identifier.
DKIM is distinctive, in that it provides an identifier which is not
necessarily related to any other identifier in the message. Hence,
the signer might be the author's ADMD, one of the operators along the
transit path, or a reputation service being used by one of those
handling services. In fact, a message can have multiple signatures,
possibly by different of these actors.
As discussed above, the choice of identifiers needs to be based on
differences that the signer thinks will be useful for the recipient
Assessor. Over time, industry practices establish norms for these
choices.
Absent such norms, it is best for signers to distinguish among
streams that have significant differences, while consuming the
smallest number of identifiers possible. This will limit the
burden on recipient Assessors.
A common view about a DKIM signature is that it carries a degree of
assurance about some or all of the message contents, and in
particular that the RFC5322.From field is likely to be valid. In
fact, DKIM makes assurances only about the integrity of the data and
not about its validity. Still, presumptions of From: field validity
remain a concern. Hence a signer using a domain name that is
unrelated to the domain name in the From: field can reasonably expect
that the disparity will warrant some curiosity, at least until
signing by independent operators has produced some established
practice among recipient Assessors.
2.5. Filtering
After assessing the signer of a message, each receiving site creates
and tunes its own Handling Filter according to criteria specific for
that site. Still, there are commonalities across sites, and this
section offers a discussion, rather than a specification, of some
types of input to that process and how they can be used.
The discussion focuses on variations in Organizational Trust versus
Message Risk. That is, the degree of positive assessment of a DKIM-
signing organization, and the potential danger present in the message
stream signed by that organization. While it might seem that higher
trust automatically means lower risk, the experience with real-world
operations provides examples of every combination of the two factors,
as shown in Table 1. Only 3 levels of granularity are listed, in
order to keep discussion manageable. This also ensures extensive
flexibility for each site's detailed choices.
+---+---------------------+--------------------+--------------------+
| | Low | Medium | High |
| | | | |
| | | | |
| | | | |
| | | | |
| O | | | |
| R | | | |
| G | | | |
| | | | |
| T | | | |
| R | | | |
| U | | | |
| S | | | |
| T | | | |
| | | | |
| M | | | |
+---+---------------------+--------------------+--------------------+
| * | Unknown org, | Registered org, | Good Org, |
| L | Few msgs: | New Identifier: | Good msgs: |
| o | _Mild filtering_ | _Medium filtering_ | _Avoid FP(!)_ |
| w | | | |
| * | Unknown org, | Registered org, | Good org, Bad msg |
| M | New Identifier: | Mixed msgs: | burst: |
| e | _Default filtering_ | _Medium filtering_ | _Accept & Contact_ |
| d | | | |
| i | | | |
| u | | | |
| * | Black-Listed org, | Registered org, | Good org, |
| H | Bad msgs: | Bad msgs: | Compromised: |
| i | _Avoid FN(!)_ | _Strong filtering_ | _Fully blocked_ |
| g | | | |
| h | | | |
+---+---------------------+--------------------+--------------------+
Table 1: Organizational Trust vs. Message Risk
The table indicates preferences for different handling of different
combinations, such as tuning filtering to avoid False Positives (FP)
or avoiding False Negatives (FN). Perhaps unexpectedly, it also
lists a case in which the receiving site might wish to deliver
problematic mail, rather than redirecting it, but also of course
contacting the signing organization, seeking resolution of the
problem.
3. DKIM Key Generation, Storage, and Management
By itself, verification of a digital signature only allows the
verifier to conclude with a very high degree of certainty that the
signature was created by a party with access to the corresponding
private signing key. It follows that a verifier requires means to
(1) obtain the public key for the purpose of verification and (2)
infer useful attributes of the key holder.
In a traditional Public Key Infrastructure (PKI), the functions of
key distribution and key accreditation are separated. In DKIM, these
functions are both performed through the DNS [RFC4871] (Allman, E.,
Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas,
"DomainKeys Identified Mail (DKIM) Signatures," May 2007.).
In either case, the ability to infer semantics from a digital
signature depends on the assumption that the corresponding private
key is only accessible to a party with a particular set of
attributes. In traditional PKI a Trusted Third Party (TTP) vouches
that the key holder has been validated with respect to a specified
set of attributes. The range of attributes that may be attested in
such a scheme is thus limited only to the type of attributes that a
TTP can establish effective processes for validating.
In DKIM, TTPs are not employed and the functions of key distribution
and accreditation are combined. Consequently there are only two
types of inference that a signer may make from a key published in a
DKIM Key Record:
1. That a party with the ability to control DNS records within a DNS
zone intends to claim responsibility for messages signed using
the corresponding private signature key.
2. That use of a specific key is restricted to a particular subset
of messages.
The ability to draw any useful conclusion from verification of a
digital signature relies on the assumption that the corresponding
private key is only accessible to a party with a particular set of
attributes. In the case of DKIM, this means that the party that
created the corresponding DKIM key record in the specific zone
intended to claim responsibility for the signed message.
Ideally we would like to draw a stronger conclusion, that if we
obtain a DKIM key record from the DNS zone example.com, that the
legitimate holder of the DNS zone example.com claims responsibility
for the signed message. In order for this conclusion to be drawn it
is necessary for the verifier to assume that the operational security
of the DNS zone and corresponding private key are adequate.
3.1. Private Key Management: Deployment and Ongoing Operations
Access to signing keys must be carefully managed to prevent use by
unauthorized parties and to minimize the consequences should a
compromise occur.
While a DKIM signing key is used to sign messages on behalf of many
mail users, the signing key itself should be under direct control of
as few key-holders as possible. Should a key-holder leave the
organization, all signing keys held by that key holder should be
withdrawn from service and if appropriate, replaced.
If key management hardware support is available, it should be used.
If keys are stored in software, sppropriate file control protections
must be employed and any location in which the private key is stored
in plaintext form should be excluded from regular backup processes
and should not be accessible through any form of network including
private local area networks. Auditing software should be used
periodically to verify that the permissions on the private key files
remain secure.
Wherever possible a signature key should exist in exactly one
location and be erased when no longer used. Ideally a signature key
pair should be generated as close to the signing point as possible
and only the public key component transferred to another party. If
this is not possible, the private key MUST be transported in an
encrypted format that protects the confidentiality of the signing
key. A shared directory on a local file system does not provide
adequate security for distribution of signing keys in plaintext form.
Key escrow schemes are not necessary and should not be used. In the
unlikely event of a signing key becomming lost, a new signature key
pair may be generated as easily as recovery from a key escrow scheme.
Responsibility for the security of a signing key should ultimately
vest in a single named individual. Where multiple parties are
authorized to sign messages, each signer should use a different key
to enable accountability and auditing.
Best practices for management of cryptographic keying material
require keying material to be refreshed at regular intervals,
particular where key management is achieved through software. While
this practice is highly desirable it is of considerably less
importance than the requirement to maintain the secrecy of the
corresponding private key. An operational practice in which the
private key is stored in tamper proof hardware and changed once a
year is considerably more desirable than one in which the signature
key is changed on an hourly basis but maintained in software.
3.2. Storing Public Keys: DNS Server Software Considerations
In order to use DKIM a DNS domain holder requires (1) the ability to
create the necessary DKIM DNS records and (2) sufficient operational
security controls to prevent insertion of spurious DNS records by an
attacker.
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. If the best practices for private key management
described above are observed, such deployment is not a one time
event, DNS DKIM selectors will be changed over time signing keys are
terminated and replaced.
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 allow the server administrators to add free-form TXT records. must allow the server administrators to add free-form TXT records.
It would be better if the the DKIM records could be entered using a It would be better if the the DKIM records could be entered using a
structured form, supporting the DKIM-specific fields. structured form, supporting the DKIM-specific fields.
2.2.4. Private Key Management: Deployment and Ongoing Operations Ideally DNSSEC [] should be employed in a configuration that provides
protection against record insertion attacks and zone enumeration. In
the case that NSEC3 [RFC 5155] records are employed to prevent
insertion attack, the OPT-OUT flag must be set clear.
The permissions of private key files must be carefully managed. If 3.2.1. Assignment of Selectors
key management hardware support is available, it should be used.
Auditing software should be used periodically to verify that the
permissions on the private key files remain secure.
2.3. DNS Signature Record Deployment and Maintenance Considerations Selectors are assigned according to the administrative needs of the
signing domain, such as for rolling over to a new key or for
delegating of the right to authenticate a portion of the namespace to
a trusted third party. Examples include:
Even with use of the DNS, one challenge is that DNS record management jun2005.eng._domainkey.example.com
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 widget.promotion._domainkey.example.com
should be changed over time. Some reasons for changing DKIM
selectors are well understood, while others are still theoretical.
There are several schemes that may be used to determine the policies
for changing DKIM selectors:
o time based It is intended that assessments of DKIM identities be based on the
domain name, and not include the selector. While past practice of a
signer may permit a verifier to infer additional properties of
particular messages from the structure DKIM key selector, unannounced
administrative changes such as a change of signing softeware may
cause such heuristics to fail at any time.
o associations with clusters of servers 3.3. Per User Signing Key Management Issues
o the use of third party signers
o security considerations While a signer may establish business rules, such as issue of
individual signature keys for each end-user, DKIM makes no provision
for communicating these to other parties. Out of band distribution
of such business rules is outside the scope of DKIM. Consequently
there is no means by which external parties may make use of such keys
to attribute messages with any greater granularity than a DNS domain.
A potential mistake in creating the DNS key record is the erroneous If per-user signing keys are assigned for internal purposes (e.g.
use of a backslash (\) in the definition. Some implementations authenticating messages sent to an MTA for distribution), the
reading a zone file allow a backslash to be used anywhere, stripping following issues need to be considered before using such signatures
any such occurrences. Other implementations only allow it to be used as an alternative to traditional edge signing at the outbound MTA:
in front of an quotation mark, storing the backslash in the record
and causing a syntax error to be generated by DKIM implementations
reading the record.
2.3.1. Time Basis and Security Considerations External verifiers will be unable to make use of the additional
signature granularity without access to additional information
passed out of band with respect to DKIM-base.
The reason for changing the selector periodically is usually related If the number of user keys is large, the efficiency of local
to the security exposure of a system. When the potential exposure of caching of key records by verifiers will be lower.
the private keys associated with the DKIM selector have reached
sufficient levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in deciding when
the exposure has reached sufficient levels to warrant changing the
selector.)
For example, A large number of end users may be less likely to be able to
manage private key data securely on their personal computer than
an administrator running an edge MTA.
o Selectors should be changed more frequently on systems that are 3.4. Third Party Signer Key Management and Selector Administration
widely exposed, than on systems that are less widely exposed. For
example, a gateway system that has numerous externally-accessible
services running on it is more widely exposed than one that ONLY
runs a mail server.
o Selectors should be changed more frequently on operating systems A DKIM key record only asserts that the holder of the corresponding
that are under wide attack. domain name makes a claim of responsibility for messages signed under
the corresponding key. In some applications, such as bulk mail
delivery it is desirable to delegate the ability to make a claim of
responsibility to another party. In this case the trust relationship
is established between the domain holder and the verifier but the
private signature key is held by a third party.
o While the use of DKIM information is transient, keys with Signature keys used by a third party signer should be kept entirely
sufficient exposure do become stale and should be changed. separate from those used by the domain holder and other third party
signers. As with any other private key, the signature key pair
should be generated by the third party signer and the public
component of the key transmitted to the domain holder rather than
have the domain holder generate the key pair and transmit the private
component to the third party signer.
o Whenever you make a substantial system change, such as bringing up Domain holders should adopt a least privilege approach and grant
a new server, or making a major operating system change, you third party signers the minimum access necessary to perform the
should consider changing the selector. desired function. Limiting the access granted to Third Party Signers
serves to protect the interests of both parties. The domain holder
minimizes their security risk and the Trusted Third Party Signer
avoids unnecessary liability.
[[anchor14: above you refer to changing the key, here you refer to In the most restrictive case a domain holder maintains full control
changing the selector; they have not been explicitly declared as over the creation of key records and employ appropriate key record
synonymous so this could be confusing]] restrictions to enforce restrictions on the messages for which the
third party signer is able to sign. If such restrictions are
impractical, the domain holder should delegate a DNS subzone for
publishing key records to the third party signer. The domain holder
should not allow a third party signer unrestricted access to their
DNS service for the purpose of publishing key records.
o Whenever there is either suspicion or evidence of the compromise 3.5. Key Pair / Selector Lifecycle Management
of the system or the private keys, you should change the selector.
2.3.2. Deploying New Selectors Deployments should establish, document and observe processes for
managing the entire lifecycle of a public key pair.
A primary consideration in changing the selector is remembering to 3.5.1. Example Key Deployment Process
change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new
selectors.
When deploying a new selector, it needs to be phased in: When it is determined that a new key pair is required:
1. Generate the new public / private key pair and create a new 1. A Key Pair is generated by the signing device
selector record with the public key in it.
2. Add the new selector record to your DNS. 2. A proposed key selector record is generated and transmitted to
the DNS administration infrasrtructure.
3. Verify that the new selector record can be used to verify 3. The DNS administration infrastructure verifies the authenticity
signatures. of the key selector registration request. If accepted
4. Turn on signing with the new private key. 1. A key selector is assigned.
5. Remove the old private key from your servers. 2. The corresponding key record published in the DNS.
6. After a period of time, remove the old selector from your DNS. 3. Wait for DNS updates to propagate (if necessary).
The time an unused selector should be kept in the DNS system is 4. Report assigned key selector to signing device.
dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable.
[[anchor16: interesting; should we have included a "u=" ('until') tag 4. Signer verifies correct registration of the key record.
on key records allowing an advertised "good until" timestamp?]]
2.3.3. Subdomain Considerations 5. Signer begins generating signatures using the new key pair.
A Domain Name is the basis for making differential quality 6. Signer terminates any private keys that are no longer required
assessments about a DKIM-signed message. It is reasonable for a due to issue of replacement.
single organization to have a variety of very different activities,
which warrant a variety of very different assessments. A convenient
way to distinguish among such activities is to sign with different
domain names. That is, the organization should sign with sub-domain
names that are used for different organizational activities.
2.3.4. Delegating Signing Authority to a Third party 3.5.2. Example Key Termination Process
Allowing third parties to sign email from your domain opens your When it is determined that a private signature key is no longer
system security to include the security of the third party's systems. required:
At a minimum, you should not allow the third parties to use the same
selector and private key as your main mail system. It is recommended
that each third party be given its own private key and selector.
This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed.
3. Signing 1. Signer stops using the private key for signature operations.
3.1. Deployment 2. Signer deletes all records of the private key, including in-
memory copies at the signing device.
Creating messages that have DKIM signatures requires a modification 3. Signer notifies the DNS administration infrasrtructure that the
to only two portions of the email service: signing key is withdrawn from service and that the corresponding
key records may be withdrawn from service at a specified future
date.
o Addition of relevant DNS information. 4. The DNS administration infrastructure verifies the authenticity
of the key selector termination request. If accepted
o Addition of the signature by a trusted module within the 1. The key selector is scheduled for deletion at a future time
organization's email handling service. determined by site policy.
The signing module uses the appropriate private key to create a 2. Wait for deletion time to arrive
signature. The means by which the signing module obtains the private
key is not specified by DKIM. Given that DKIM is intended for use
during email transit, rather than for long-term storage, it is
expected that keys will be changed regularly. Clearly this means
that key information should not be hard-coded into software.
3.1.1. DNS Records 3. The key selector is deleted
A receiver attempting to verify a DKIM signature must obtain the 4. Signing
public key that is associated with the signature for that message.
The DKIM-Signature header in the message will specify the basic Creating messages that have one or more DKIM signatures, requires
domain name doing the signing and the selector to be used for the support in only two outbound email service components:
specific public key. Hence, the relevant
o A DNS Administrative interface that can create and maintain the
relevant DNS names -- including names with underscores -- and
resource records (RR).
o A trusted module, called the Signing Module, which is within the
organization's outbound email handling service and which creates
and adds the DKIM-Signature: header field(s) to the message.
If the module creates more than one signature, there needs to be the
appropriate means of telling it which one(s) to use. If a large
number of names is used for signing, it will help to have the
administrative tool support a batch processing mode.
4.1. DNS Records
A receiver attempting to verify a DKIM signature obtains the public
key that is associated with the signature for that message. The
DKIM-Signature: header in the message contains the d= tag with the
basic domain name doing the signing and serving as output to the
Identity Assessor, and the s= tag with the selector that is added to
the name, for finding the specific public key. Hence, the relevant
<selector>._domainkey.<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 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 support DKIM names, such as with underscores, and to
add new types of DNS information.
3.1.2. Signing Module 4.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 obvious choices include department-level posting agents, as well as
delivering agents, as well as boundary MTAs to the open Internet. outbound boundary MTAs to the open Internet. However any other
(Note that it is entirely acceptable for MUAs to perform signing and module, including the author's MUA, is potentially acceptable, as
verification.) Hence the choice among the modules depends upon long as the signature survives any remaining handling within the
software development and administrative overhead tradeoffs. ADMD. Hence the choice among the modules depends upon software
development, administrative overhead, security exposures and transit
[[anchor23: See earlier note about signing by MUAs being a security handling tradeoffs. One perspective that helps to resolve this
concern]] One perspective that helps resolve this choice is the choice is the difference between the increased flexibility, from
difference between the flexibility of use by systems at (or close to) placement at (or close to) the MUA, versus the streamlined
the MUA, versus the centralized control that is more easily obtained administration and operation, that is more easily obtained by
by implementing the mechanism "deeper" into the organization's email implementing the mechanism "deeper" into the organization's email
infrastructure, such as at its boundary MTA. infrastructure, such as at its boundary MTA.
3.1.3. DKIM Signing Software Development Note the discussion in Section 2.2, concerning use of the i= tag.
Signer implementations should provide a convenient means of The signing module uses the appropriate private key to create one or
generating DNS key records corresponding to the signer configuration. more signatures. The means by which the signing module obtains the
Support for automatic insertion of key records into the DNS is also private key(s) is not specified by DKIM. Given that DKIM is intended
highly desirable. If supported however, such mechanism(s) must be for use during email transit, rather than for long-term storage, it
properly authenticated. is expected that keys will be changed regularly. For administrative
convenience, key information should not be hard-coded into software.
A means of verifying that the signer configuration is compatible with 4.3. Signing Policies and Practices
the signature policy is also highly desirable.
Disclosure of a private signature key component to a third party Every organization (ADMD) will have its own policies and practices
allows that third party to impersonate the sender. The protection of for deciding when to sign messages (message stream) and with what
private signature key data is therefore a critical concern. Signers domain name, selector and key. Examples of particular message
should support use of cryptographic hardware providing key management streams include all mail sent from the ADMD, versus mail from
features. particular types of user accounts, versus mail having particular
types of content. Given this variability, and the likelihood that
signing practices will change over time, it will be useful to have
these decisions represented through run-time configuration
information, rather than being hard-coded into the signing software.
3.1.3.1. Signer Actions As noted in Section 2.3, the choice of signing name granularity
requires balancing administrative convenience and utility for
recipients. Too much granularity is higher administrative overhead
and well might attempt to impose more differential analysis on the
recipient than they wish to support. In such cases, they are likely
to use only a super-name -- right-hand substring -- of the signing
name. When this occurs, the signer will not know what portion is
being used; this then moves DKIM back to the non-deterministic world
of heuristics, rather than the mechanistic world of signer/recipient
collaboration that DKIM seeks.
All Signers should: 5. Verifying
o Include any existing Sender header field in the signed header To be added.
field list, if the Sender header field exists.
o ... 6. Taxonomy of Signatures
Signers wishing to avoid the use of Third-Party Signatures should do A DKIM signature tells the signature verifier that the owner of a
everything listed above, and also: particular domain name accepts some responsibility for the message.
It does not, in and of itself, provide any information about the
trustworthiness or behavior of that identity. What it does provide
is a verified identity to which such behavioral information can be
associated, so that those who collect and use such information can be
assured that it truly pertains to the identity in question.
o Include the Sender header field name in the header field list This section lays out a taxonomy of some of the different identities,
("h=" tag) under all circumstances, even if the Sender header or combinations of identities, that might usefully be represented by
field does not exist in the header block. This prevents another a DKIM signature.
entity from adding a Sender header field.
o Publish Signing Practices that do not sanction the use of Third- 6.1. Single Domain Signature
Party Signatures.
3.1.4. Signing Policies and Practices Perhaps the simplest case is when an organization signs its own
outbound email using its own domain in the d= tag of the signature.
For example, Company A would sign the outbound mail from its
employees with d=companyA.example.
Every organization (ADMD) will have its own policies and practices In the most straightforward configuration, the addresses in the RFC
for deciding when to sign messages and with what domain name and key 5322 From would also be in the companyA.example domain, but that
(selector). Examples include signing all mail, signing mail from direct correlation is not required.
particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing
practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software.
3.2. Mailing Lists A special case of the Single Domain Signature is an Author Signature
as defined by the Author Domain Signing Practices specification.
Author signatures are signatures from an authors organization that
have an i= value that matches the From: address of the message.
Under the ADSP specification, an i= value matches a RFC 5322 From
address when the domains of the two match exactly, and if the i=
value contains a local part it also matches the local part of the
From: address exactly.
A mailing list often provides facilities to its administrator to Although an author signature might in some cases be proof against
manipulate parts of the mail messages that flow through the list. domain name spoofing the RFC 5322 From address, it is important to
The desired goal is that messages flowing through the mailing list note that the DKIM and ADSP validation apply only to the exact
will be verifiable by the recipient as being from the list, or address string and not to look-alike addresses nor to the human-
failing that, as being from the individual list members. friendly "display-name" or names and addresses used within the body
of the message. That is, it protects only against the misuse of a
precise address string within the RFC5322 From field and nothing
else. For example, a message from bob@domain.example with a valid
signature where i=d0main.example would fail an ADSP check because the
signature domain, however similar, is distinct; however a message
from bob@d0main.example with a valid signature where i=d0main.example
would pass an ADSP check, even though to a human it might be obvious
that d0main.example is likely a malicious attempt to spoof the domain
domain.example. This example highlights that ADSP, like DKIM, is
only able to validate a signing identifier: it still requires some
external process to attach a meaningful reputation to that
identifier.
There are several forms of mailing lists, which interact with signing 6.2. Parent Domain Signature
in different ways.
o "Verbatim" mailing lists send messages without modification Another approach that might be taken by an organization with multiple
whatsoever. They are often implemented as MTA-based aliases. active subdomains is to apply the same (single) signature to mail
Since they do not modify the message, signatures are unaffected from all subdomains. In this case, the signature chosen would
and will continue to verify. It is not necessary for the usually be the signature of a parent domain common to all subdomains.
forwarder to re-sign the message; however, some may choose to do For example, mail from marketing.domain.example,
so in order to certify that the message was sent through the list. sales.domain.example, and engineering.domain.example might all use a
signature with d=domain.example.
o "Digesting" mailing lists collect together one or more postings This approach has the virtue of simplicity, but it is important to
and then retransmit them, often on a nightly basis, to the consider the implications of such a choice. As discussed in
subscription list. These are essentially entirely new messages Section 2.3, if the type of mail sent from the different subdomains
which must be independently authored (that is, they will have a is significantly different or if there is reason to believe that the
"From" header field referring to the list, not the submitters) and reputation of the subdomains would differ, then it may be a good idea
signed by the Mailing List Manager itself, if they are signed at to acknowledge this and provide distinct signatures for each of the
all. subdomains (d=marketing.domain.example, sales.domain.example, etc.).
However, if the mail and reputations are likely to be similar, then
the simpler approach of using a single common parent domain in the
signature may work well.
o "Resending" mailing lists receive a message, modify it (often to Another approach to distinguishing the streams using a single DKIM
add "unsubscribe" information or advertising), and immediately key would be to leverage the i= tag in the DKIM signature to
resend that message to the subscription list. They are differentiate the mail streams. For example, marketing email would
problematic because they usually do not change the "From" header be signed with i=marketing.domain.example and d=domain.example.
field of the message, but they do invalidate the signature in the
process of modifying the message.
In most cases, the list and/or its mail host should add its own DKIM It's important to remember, however, that under core DKIM semantics
signature to list mail. This could be done in the list management the i= identifer is opaque to receivers. That means that it will
software, in an outgoing MSA or MTA, or both. List management only be an effective differentiator if there is an out of band
software often makes modifications to messages that will break agreement about the i= semantics (e.g., the semantics specified in
incoming signatures, such as adding subject tags, adding message ADSP).
headers or footers, and adding, deleting, or reordering MIME parts.
By adding its own signature after these modifications, the list
provides a verifiable, recognizable signature for list recipients.
In some cases, the modifications made by the mailing list software 6.3. Third Party Signature
are simple enough that signatures on incoming messages will still be
verifiable after being remailed by the list. It is still preferable
that the list sign its mail so that recipients can distinguish
between mail sent through the list and mail sent directly to a list
member. In the absence of a list signature, a recipient may still be
able to recognize and use the original signatures of the list
members.
The first two cases act in obvious ways and do not require further A signature whose domain does not match the domain of the RFC 5322
discussion. The remainder of this session applies only to the third From address is sometimes referred to as a third party signature. In
case. certain cases even the parent domain signature described above would
be considered a third party signature because it would not be an
exact match for the domain in the From: address.
3.2.1. Mailing List Manager Actions Although there is often heated debate about the value of third-party
signatures, it is important to note that the DKIM specification
attaches no particular significance to the identity in a DKIM
signature. The identity specified within the signature is the
identity that is taking responsibility for the message, and it is
only the interpretation of a given receiver that gives one identity
more or less significance than another. In particular, most
independent reputation services assign trust based on the specific
identifier string, not its "role": in general they make no
distinction between, for example, an author signature and a third
party signature.
Mailing List Managers should make every effort to ensure that For some, a signature unrelated to the author (identity in the RFC
messages that they relay and which have Valid Signatures upon receipt 5322 From address) is less valuable because there is an assumption
also have Valid Signatures upon retransmission. In particular, that the presence of an author signature guarantees that the use of
Mailing List Managers that modify the message in ways that break the address in the From: header is authorized.
existing signatures should:
o Verify any existing DKIM Signatures. A DKIM-aware Mailing List For others, that relevance is tied strictly to the recorded
Manager must NOT re-sign an improperly signed message in such a behavioral data assigned to the identity in question, i.e. its trust
way that would imply that the existing signature is acceptable. assessment or reputation. The reasoning here is that an identity
with a good reputation is unlikely to maintain that good reputation
if it is in the habit of vouching for messages that are unwanted or
abusive; in fact, doing so will rapidly degrade its reputation so
that future messages will no longer benefit from it. It is therefore
low risk to facilitate the delivery of messages that contain a valid
signature of a domain with a strong positive reputation, independent
of whether or not that domain is associated with the address in the
RFC5322 From header field of the message.
o Apply regular anti-spam policies. A Mailing List Manager should Third party signatures encompass a wide range of identities. Some of
apply message content security policy just as would be done to the more common are:
messages destined for an individual user's mailbox. In fact, a
Mailing List Manager might apply a higher standard to messages
destined to a mailing list than would normally be applied to
individual messages.
NON-NORMATIVE RATIONALE: Since reputation will accrue to signers,
Mailing List Managers should verify the source and content of
messages before they are willing to sign lest their reputation be
sullied by nefarious parties.
o Add a Sender header field using a valid address pointing back to Service Provider: In cases where email is outsourced to an Email
the Mailing List Administrator or an appropriate agent (such as an Service Provider (ESP), Internet Service Provider (ISP), or other
"owner-" or a "-request" address). type of service provider, that service provider may choose to DKIM
sign outbound mail with either its own identifier -- relying on
its own, aggregate reptutation -- or with a subdomain of the
provider that is unique to the message author but still part of
the provider's aggregate reputation. Such service providers may
also encompass delegated business functions such as benefit
management, although these will more often be treated as trusted
third party senders (see below).
o Sign the resulting message with a signature that is valid for the Parent Domain. As discussed above, organizations choosing to sign
Sender header field address. The Mailing List Manager should NOT for mail originating from subdomains with a parent domain
sign messages for which they are unwilling to accept signature may also considered to be using 3rd party signatures in
responsibility. some configurations, depending on whether or not the "t=s" tag is
used to constrain the parent signature to apply to only its own
specific domain. The default is that a parent domain signature is
considered valid for its subdomains.
Mailing List Managers MAY: Reputation Provider: Another possible category of third party
signature would be the identity of a 3rd party reputation
provider. Such a signature would indicate to receivers that the
message was being vouched for by that 3rd party.
o Reject messages with signatures that do not verify or are 6.4. Using Trusted 3rd Party Senders
otherwise Suspicious.
[[anchor29: Is "Suspicious" still a formal term in DKIM?]] For most of the cases described so far, there has been an assumption
that the identity doing the signing was responsible for creating and
maintaining their own DKIM signing infrastructure, including their
own keys, and signing with their own identity.
3.3. Signature Transition Strategy A different model arises when an organization uses a trusted third
party sender for certain key business functions, but still wants that
email to benefit from the organization's own identity and reputation:
in other words, the mail would come out of the trusted 3rd party's
mail servers, but the signature applied would be that of the
controlling organization.
[[anchor31: I'm not entirely clear what is meant by "algorithm" This can be done by having the 3rd party generate a key pair that is
beyond the combination of key, selector, and signing parameters designated uniquely for use by that trusted 3rd party and publishing
included in the DKIMSignature header. Unless I'm way off base, I the public key in the controlling organization's DNS domain, thus
think this section belongs either here under "Signing", or in section enabling the third party to sign mail using the signature of the
1 under "Key Generation, Storage, and Management". Either way, we controlling organization. For example, if Company A outsources its
should be more clear about what is meant by the term "signature employee benefits to a 3rd party, they can use a special keypair that
algorithm".]] enables the benefits company to sign mail as "companyA.example".
Because the keypair is unique to that trusted 3rd party, it is easy
for Company A to revoke the authorization if necessary by simply
removing the public key from the companyA.example DNS.
Deployment of a new signature algorithm without a 'flag day' requires In this scenario, it is usually a good idea to limit the specific
a transition strategy such that signers and verifiers can phase in identities that can be used by even trusted third parties. The DKIM
support for the new algorithm independently, and (if necessary) phase g= tag enables a key record to specify one particular From: address
out support for the old algorithm independently. local part that must be specified in the i= tag of the signature: for
example, "g=benefits" would require a signature header tag of
"i=benefits@companyA.example". It is important to note that although
this distinction will be clear to the verifier it may be invisible to
the recipient: there is no constraint within the DKIM verification
process that constrains that specific i= value to correspond to any
of the other message headers.
[Note: this section assumes that a security policy mechanism exists. A more reliable way of distinguishing the third part mail stream
It is subject to change.] would be to create a dedicated subdomain (e.g.
benefits.companyA.example) and publish the public key there; the
signature would then use d=benefits.companyA.example.
[[anchor32: safe to presume ADSP?]] 6.4.1. DNS Delegation
DKIM achieves these requirements through two features: First, a Another possbility for configuring trusted third party access is to
signed message may contain multiple signatures created by the same have Company A use DNS delegation and have the designated subdomain
signer. Second, the security policy layer allows the signing managed directly by the trusted third party. In this case, Company A
algorithms in use to be advertised, thus preventing a downgrade would create a subdomain benefits.companya.example, and delegate the
attack. DNS management of that subdomain to the benefits company so it could
maintain its own key records. Should revocation become necessary,
Company A could simply remove the DNS delegation record.
3.3.1. Signer transition strategy 6.5. Multiple Signatures
Let the old signing algorithm be A and the new signing algorithm be A simple configuration for DKIM-signed mail is to have a single
B. The sequence of events by which a Signer may introduce the new signature on a given message. This works well for domains that
signing algorithm B, without disruption of service to legacy manage and send all of their own email from a single source, or for
verifiers, is as follows: cases where multiple email streams exist but each has its own unique
key pair. It also represents the case in which only one of the
participants in an email sequence is able to sign, no matter whether
they represent the author or one of the operators.
1. Signer signs with algorithm A The examples thus far have considered the implications of using
different identities in DKIM signatures, but have used only one such
identity for any given message. In some cases, it may make sense to
have more than one identity claiming responsiblity for the same
message.
A. Signer advertises that it signs with algorithm A One important caveat to the use of multiple signatures is that there
2. Signer signs messages twice, with both algorithm A and algorithm is currently no clear consensus amoung receivers on how they plan to
B handle them. The opinions range from ignoring all but one signature
(and the specification of which of them is verified differs from
receiver to receiver), to verifying all signatures present and
applying a weighted blend of the trust assessments for those
identifiers, to verifying all signatures present and simply using the
identfier that represents the most positive trust assessment. It is
likely that the industry will evolve to accept multiple signatures
using either option two or three, but it may take some time before
that approach becomes pervasive.
A. The signer tests new signing configuration There are a number of situations where applying more than one DKIM
signature to the same message might make sense. A few examples are:
B. Signer advertises that it signs with either algorithm A or Companies with multiple subdomain identities: A company that has
algorithm B multiple subdomain sending distinct categories of mail might
choose to sign with distinct subdomain identities to enable each
subdomain to manage its own identity. However, it might also want
to provide a common identity that cuts across all of the distinct
subdomains. For example, Company A may sign mail for its sales
department with a signature where d=marketing.companya.example,
and a second signature where d=companya.example
3. Signer determines that support for Algorithm A is no longer Service Providers: Service providers may, as described above, choose
necessary to sign outbound messages with either their own identity or with
an identity unique to each of their clients (possibly delegated).
However, they may also do both: sign each outbound message with
their own identity as well as the identity of each individual
client. For example, ESP A might sign mail for their client
Company B with their service provider signature d=espa.example,
and a second client-specific signature where d= either
companyb.example, or companyb.espa.example. The existence of the
service provider signature could, for example, help cover a new
client while they establish their own reputation, or help a very
small volume client who might never reach a volume threshold
sufficient to establish an individual reputation.
4. Signer determines that support for algorithm A is to be withdrawn Forwarders Forwarded mail poses a number of challenges to email
authentication. DKIM is relatively robust in the presence of
forwarders as long as the signature is designed to avoid message
parts that are likely to be modified, although some forwarders do
make modifications that can invalidate a DKIM signature.
A. Signer removes advertisement for Algorithm A However, some forwarders such as mailing lists or forward article
to a friend services, might choose to add their own signature to
outbound messages to vouch for it having legitimately originated
from the designated service. In this case, the signature would be
added even in the presence of a pre-existing signature, and both
signatures would be relevant to the verifier.
B. Signer waits for cached copies of earlier signature policy to Any forwarder that modifies messages in ways that will break pre-
expire existing DKIM signatures should always sign its forwarded
messages.
C. Signer stops signing with Algorithm A Reputation Providers: Although third party reputation providers
today use a variety of protocols to communicate their information
to receivers, it is possible that they, or other organizations
willing to put their "seal of approval" on an email stream might
choose to use a DKIM signature to do it. In nearly all cases,
this "reputation" signature would be in addition to the author or
originator signature.
3.3.2. Verifier transition strategy 7. Example Usage Scenarios
The actions of the verifier are independent of the signer's actions Signatures are created by different types of email actors, based on
and do not need to be performed in a particular sequence. The different criteria, such as where the actor operates in the sequence
verifier may make a decision to cease accepting algorithm A without from author to recipient, whether they want different messages to be
first deploying support for algorithm B. Similarly a verifier may be evaluated under the same reputation or different, and so on. This
upgraded to support algorithm B without requiring algorithm A to be section provides some examples of usage scenarios for DKIM
withdrawn. The decisions of the verifier must make are therefore: deployments; the selection is not intended to be exhaustive, but to
illustrate a set of key deployment considerations.
o The verifier MAY change the degree of confidence associated with 7.1. Author's Organization - Simple
any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity
at a given key strength.
* A verifier MAY evaluate signature records in any order it The simplest DKIM configuration is to have all mail from a given
chooses, including using the signature algorithm to choose the organization (Company A) be signed with the same d= value (e.g.
order. d=companya.example). If there is a desire to associate a user
identity or some other related information, the i= value can become
uniqueID@companya.example, or uniqueID.companya.example.
o The verifier MAY make a determination that Algorithm A does not In this scenario, Company A need only generate a single signing key
offer a useful level of security, or that the cost of verifying and publish it under their top level domain (companya.example); the
the signature is less than the value of doing so. signing module would then tailor the i= value as needed at signing
time.
* In this case the verifier would ignore signatures created using 7.2. Author's Organization - Differentiated Types of Mail
algorithm A and references to algorithm A in policy records
would be treated as if the algorithm were not implemented.
o The verifier MAY decide to add support for additional signature A slight variation of the one signature case is where Company A signs
algorithms at any time. all of its mail, but it wants to differentiate different categories
of its outbound mail by using different identifiers. For example, it
might choose to distinguish marketing mail, billing or transactional
mail, and individual corporate email into marketing.companya.example,
billing.companya.example, and companya.example, where each category
is assigned a unique subdomain and unique signing keys.
* The verifier MAY add support for algorithm B at any time. 7.3. Author Signature
4. Verifying As discussed in Section 6.1, author signatures are a special case of
signatures from an authors organization where at least one signature
on the message has an i= value that matches the From: address of the
message.
4.1. Verifier Signers wishing to publish an ADSP record describing their signing
practices will want to include an author signature on their outbound
mail to avoid ADSP verification failures. For example, if the
address in the RFC 5322 From is bob@company.example, the d= value of
the author signature would be company.example, and the i= value would
be either company.example or bob@company.example.
Verifiers should treat the result of the verification step as an 7.4. Author Domain Signing Practices
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 To be added.
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. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP
Verification is performed within an ADMD that wishes to make 7.5. Delegated Signing
assessments based upon the DKIM signature's domain name. Any
component within the ADMD that handles messages, whether in transit
or being delivered, can do the verifying and subsequent assessments.
Verification and assessment might occur within the same software
mechanism, such as a Boundary MTA, or an MDA. Or they may be
separated, such as having verification performed by the Boundary MTA
and assessment performed by the MDA.
As with the signing process, choice of service venues for An organization may choose to outsource certain key services to third
verification and assessment -- such as filtering or presentation to party companies. For example, Company A might outsource its benefits
the recipient user -- depend on trade-offs for flexibility, control, management, or Organization B might outsource its marketing email.
and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: the assessment
module must have a strong basis for believing that the verification
information is correct.
4.2. DNS Client If Company A wants to ensure that all of the mail sent on its behalf
through the benefits providers email servers shares the Company A
reputation, as discussed in Section 6.4 it can either publish keys
designated for the use of the benefits provider under
companyA.example (preferably under a designated subdomain of
companyA.example), or they can delegate a subdomain (e.g.
benefits.companyA.example) to the provider and enable the provider to
generate the keys and manage the DNS for the designated subdomain.
The primary means of publishing DKIM key information, initially, is In both of these cases, mail would be physically going out of the
through DNS TXT records. Some DNS client software might have benefit provider's mail servers with a signature of e.g.
problems obtaining these records; as DNS client software improves d=benefits.companya.example. Note that the From: address is not
this will not be a concern. constrained: it could either be affiliated with the benefits company
(e.g. benefits-admin@benefitprovider.example, or
benefits-provider@benefits.companya.example).
4.3. Boundary Enforcement Note that in both of the above scenarios, security concerns dictate
that the keys be generated by the organization that plans to do the
signing so that there is no need to transfer the private key. In
other words, the benefits provider would generate keys for both of
the above scenarios.
In order for an assessment module to trust the information it 7.6. Independent Third Party Service Providers
receives about verification (e.g., Authentication-Results header
fields), it must eliminate verification information originating from
outside the ADMD in which the assessment mechanism operates. As a
matter of friendly practice, it is equally important to make sure
that verification information generated within the ADMD not escape
outside of it.
In most environments, the easiest way to enforce this is to place Another way to manage the service provider configuration would be to
modules in the receiving and sending Boundary MTA(s) that strip any have the service provider sign the outgoing mail on behalf of its
existing verification information. client Company A with its own (provider) identifier. For example, an
Email Service Provider (ESP A) might want to share its own mailing
reputation with its clients, and may sign all outgoing mail from its
clients with its own d= domain (e.g. d=espa.example).
4.4. Filtering Software Should the ESP want to distinguish among its clients, it has two
options:
Developers of filtering schemes designed to accept DKIM Share the d= domain and use the i= value to distinguish among the
authentication results as input should be aware that their clients: e.g. a signature on behalf of client A would have
implementations will be subject to counter-attack by email abusers. d=espa.example and i=clienta.espa.example (or
The efficacy of a filtering scheme cannot therefore be determined by i=clienta@espa.example)
reference to static test vectors alone; resistance to counter attack
must also be considered.
Naive learning algorithms that only consider the presence or absence Extend the d= domain so there is a unique value (and subdomain) for
of a verified DKIM signature, without considering more information each client: e.g. a signature on behalf of client A would have
about the message, are vulnerable to an attack in which spammers or d=clienta.espa.example.
other malefactors sign all their mail, thus creating a large negative
value for presence of a DKIM signature in the hope of discouraging
widespread use.
If heuristic algorithms are employed, they should be trained on Note that this scenario and the delegation scenario are not mutually
feature sets that sufficiently reveal the internal structure of the exclusive: in some cases, it may be desirable to sign the same
DKIM responses. In particular the algorithm should consider the message with both the ESP and the ESP client identities.
domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not.
Unless a scheme can correlate the DKIM signature with accreditation 7.7. Mail Streams Based on Behavioral Assessment
or reputation data, the presence of a DKIM signature should be
ignored.
5. DKIM Deployment Considerations for Email Agents An ISP (ISP A) might want to assign signatures to outbound mail from
their users according to the users past sending behavior
(reputation). Since the semantics of behavioral assessments arent
allowed as i= values, ISP A (ispa.example) would have to configure
subdomains corresponding the assessment categories (e.g.
good.ispa.example, neutral.ispa.example, bad.ispa.example), and use
these domains as the d= value of the signature.
5.1. Email Infrastructure Agents The signing module can also optionally set the i= value to have a
unique user id (distinct from the users email address local part),
for example user3456@neutral.domain.example. Using a userid that is
distinct from a given email alias is useful in environments where a
single user might register multiple email aliases.
Note that in this case the i= values are only partially stable. They
are stable in the sense that a given i= value will always represent
the same identity, but they are unstable in the sense that a given
user can migrate among the assessment subdomains depending on their
sending behavior (i.e., the same user might have multiple i= values
over the lifetime of their account).
In this scenario, ISP A would have to generate as many keys as there
are assessment subdomains (d= values), so that each assessment
subdomain had its own key. The signing module would then choose its
signing key based on the assessment of the user whose mail was being
signed, and if desired include the user id in the i= tag of the
signature.
7.8. Agent or Mediator Signatures
Another scenario is that of an agent, usually a re-mailer of some
kind, that signs on behalf of the service or organization that it
represents. Some examples of agents might be a mailing list manager,
or the "forward article to a friend" service that many online
publications offer. In most of these cases, the signature is
asserting that the message originated with, or was relayed by, the
service asserting responsibility.
8. Usage Considerations
8.1. Non-standard Submission and Delivery Scenarios
The robustness of DKIM's verification mechanism is based on the fact
that only authorized signing modules have access to the designated
private key. This has the side effect that email submission and
delivery scenarios that originate or relay messages from outside the
domain of the authorized signing module will not have access to that
protected private key, and thus will be unable to attach the expected
domain signature to those messages. Such scenarios include mailing
lists, courtesy forwarders, MTAs at hotels, hotspot networks used by
travelling users, and other paths that could add or modify headers,
or modify the message body.
For example, assume Joe works for Company A and has an email address
joe@companya.example. Joe also has a GMail account joe@gmail.com,
and he uses GMails multiple address feature to attach his work email
joe@companya.example to his GMail account. When Joe sends email from
his GMail account and uses joe@companya.example as his designated
From: address, that email cannot have a signature with
d=companya.example because the GMail servers have no access to
Company A's private key. In GMail's case it will have a GMail
signature, but for some other mail clients offering the same multiple
address feature there may be no signature at all on the message.
Another example might be the use of a forward article to a friend
service. Most instances of these services today allow someone to
send an article with their email address in the RFC 5322 From to
their designated recipient. If Joe used either of his two addresses
(joe@companya.example or joe@gmail.com), the forwarder would be
equally unable to sign with a corresponding domain . As in the mail
client case, the forwarder may either sign as its own domain, or may
put no signature on the message.
A third example is the use of privately configured forwarding.
Assume that Joe has another account at Yahoo, joe@yahoo.com, but he'd
prefer to read his Yahoo mail from his GMail account. He sets up his
Yahoo account to forward all incoming mail to joe@gmail.com. Assume
alice@companyb.example sends joe@yahoo.com an email. Depending on
how companyb.example configured its signature, and depending on
whether or not Yahoo modifies messages that it forwards, it is
possible that when Alice's message is received in Joe's gmail account
the original signature fails verification.
8.2. Protection of Internal Mail
One identity is particularly amenable to easy and accurate
assessment: the organization's own identity. Members of an
organization tend to trust messages that purport to be from within
that organization. However Internet Mail does not provide a
straightforward means of determining whether such mail is, in fact,
from within the organization. DKIM can be used to remedy this
exposure. If the organization signs all of its mail, then its
boundary MTAs can look for mail purporting to be from the
organization that does not contain a verifiable signature.
Such mail can in most cases be presumed to be spurious. However,
domain managers are advised to consider the ways that mail processing
can modify messages in ways that will invalidate an existing DKIM
signature: mailing lists, courtesy forwarders, and other paths that
could add or modify headers or modify the message body (e.g. MTAs at
hotels, hotspot networks used by travelling users, and other
scenarios described in the previous section). Such breakage is
particularly relevant in the presence of Author Domain Signing
Practices.
8.3. Signature Granularity
Although DKIM's use of domain names is optimized for a scope of
organization-level signing, it is possible to administer sub-domains
or otherwise adjust signatures in a way that supports per-user
identification. This user level granularity can be specified in two
ways: either by sharing the signing identity and specifying an
extension to the i= value that has a per-user granularity, or by
creating and signing with unique per-user keys.
A subdomain or local part in the i= tag should be treated as an
opaque identifier and thus need not correspond directly to a DNS sub
domain or to a specific user address
The primary way to sign with per-user keys require that each user
have a distinct DNS (sub)domain, where each distinct d= value has a
key published (it is possible, although not recommended, to publish
the same key in more than one distinct domain).
It is technically possible, to publish per-user keys within a single
domain or subdomain by utilizing different selector values. This is
not recommended and is unlikely to be treated uniquely by Identity
Assessors: the primary purpose of selectors is to facilitate key
management, and the DKIM specification recommends against using them
in determining or assessing identies.
In most cases, it would be impractical to sign email on a per-user
granularity. Such an approach would be
likely to be ignored: In most cases today, if receivers are
verifying DKIM signatures they are in general taking the simplest
possible approach. In many cases maintaining reputation
information at a per user granularity is not interesting to them,
in large part because the per user volume is too small to be
useful or interesting. So even if senders take on the complexity
necessary to support per user signatures, receivers are unlikely
to retain anything more than the base domain reputation.
difficult to manage: Any scheme that involves maintenance of a
significant number of public keys may require infrastructure
enhancements or extensive administrative expertise. For domains
of any size, maintaining a valid per-user keypair, knowing when
keys need to be revoked or added due to user attrition or
onboarding, and the overhead of having the signing engine
constantly swapping keys can create significant and often
unnecessary managment complexity. It is also important to note
that there is no way within the scope of the DKIM specification
for a receiver to infer that a sender intends a per-user
granularity.
What may make sense, however, is to use the infrastructure that
enables finer granularity in signatures to identify segments smaller
than a domain but much larger than a per-user segmentation. For
example, a university might want to segment student, staff, and
faculty mail into three distinct streams with differing reputations.
This can be done by creating seperate sub-domains for the desired
segments, and either specifying the subdomains in the i= tag of the
DKIM Signature or by adding subdomains to the d= tag and assigning
and signing with different keys for each subdomain.
For those who choose to represent user level granularity in
signatures, the performance and management considerations above
suggest that it would be more effective to do it by specifying a
local part or subdomain extension in the i= tag rather than by
extending the d= domain and publishing individual keys.
8.4. 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. What follows are some
general recommendations for the Email Infrastructure.
Outbound: An MSA or Outbound MTA should allow for the automatic Outbound: An MSA or an Outbound MTA used for mail submission
verification of the MTA configuration such that the MTA can SHOULD ensure that the message sent is in compliance with the
generate an operator alert if it determines that it is (1) an advertised email sending policy. It SHOULD also be able to
edge MTA, and (2) configured to send email messages that do not generate an operator alert if it determines that the email
comply with the published DKIM sending policy. messages do not comply with the published DKIM sending policy.
An outbound MTA should be aware that users may employ MUAs that An MSA SHOULD be aware that some MUAs may add their own
add their own signatures and be prepared to take steps signatures. If the MSA needs to perform operations on a
necessary to ensure that the message sent is in compliance with message to make it comply with its email sending policy, if at
the advertised email sending policy. all possible, it SHOULD do so in a way that would not break
those signatures.
[[anchor42: MUAs being able to sign is a security [[anchor38: MSK: MUAs being able to sign is a security
consideration; MUAs are more prone to vulnerabilities, so an consideration; MUAs are more prone to vulnerabilities, so an
MUA having direct access to signing keys is a security concern; MUA having direct access to signing keys is a security concern;
general MUA vulnerability came up during the IETF Security general MUA vulnerability came up during the IETF Security
Directorate review of draft-kucherawy-sender-auth-header]] Directorate review of draft-kucherawy-sender-auth-header]]
Inbound: An inbound MTA or an MDA that does not support DKIM Inbound: When an organization deploys DKIM, it needs to make
should avoid modifying messages in ways that prevent sure that it email infrastructure components that do not have
verification by other MTAs, or MUAs to which the message may be primary roles in DKIM handling do not modify message in ways
forwarded. that prevent subsequent verification.
An inbound MTA or an MDA may incorporate an indication of the An inbound MTA or an MDA may incorporate an indication of the
verification results into the message, such as using an verification results into the message, such as using an
Authentication-Results header field. Authentication-Results header field.
[I-D.kucherawy-sender-auth-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 + Incorporate an indication of the verification results into
the message, such as using an Authentication-Results header the message, such as using an Authentication-Results header
skipping to change at page 17, line 4 skipping to change at page 34, line 5
+ 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 + Incorporate an indication of the verification results into
the message, such as using an Authentication-Results header the message, such as using an Authentication-Results header
field. [I-D.kucherawy-sender-auth-header] field. [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 field). (e.g., the Authentication-Results header field).
5.2. Mail User Agent 8.5. Mail User Agent
DKIM is designed to support deployment and use in email components
other than an MUA. However an MUA MAY also implement DKIM features
directly.
Outbound: If an MUA is configured to send email directly, rather
than relay it through an outbound MSA, the MUA should be
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
through an outbound MSA. In this case the signature applied by
the MUA may be in addition to any MSA signature.
Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA
path (e.g., an Authentication-Results header field), or an MUA
MAY perform DKIM signature verification directly. A verifying
MUA should allow for the case where mail is modified in the
inbound MTA path.
It is common for components of an ADMD's email infrastructure to do
violence to a message, such as to render a DKIM signature invalid.
Hence, users of MUAs that support DKIM signing and/or verifying need
a basis for knowing that their associated email infrastructure will
not break a signature.
6. Migrating from DomainKeys
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.
[[anchor46: Explicit "g=" has different meaning in DomainKeys
and DKIM, which has been an interoperability issue in the past
(DomainKeys interprets that as "match any" while DKIM
interprets it as "match none")]]
Boundary MTA: The principal 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.
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.
7. Example Uses
A DKIM signature tells the signature verifier that the owner of a
particular domain name accepts responsibility for the message.
Combining this information with information that allows the history
of the domain name owner to be assessed may allow processing the
message, based on the probability that the message is likely to be
trustworthy, or not, without the need for heuristic content analysis.
7.1. Protection of Internal Mail
One identity is particularly amenable to easy and accurate
assessment: The organization's own identity. Members of an
organization tend to trust messages that purport to be from within
that organization. However Internet Mail does not provide a
straightforward means of determining whether such mail is, in fact,
from within the organization. DKIM can be used to remedy this
exposure. If the organization signs all of its mail, then its
boundary MTAs can look for mail purporting to be from the
organization but does not contain a verifiable signature. Such mail
can be presumed to be spurious.
WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN
SIGNATURE???? Need to include some of the breakage examples from
ADSP spec.
7.2. Recipient-based Assessments
Recipients of large volumes of email can internally generate
reputation data for email senders. Recipients of smaller volumes of
messages are likely to need to acquire reputation data from a third
party. In either case the use of reputation data is intrinsically
limited to email senders that have established a prior history of
sending messages.
In fact, an email receiving service may be in a position to establish
bilateral agreements with particular senders, such as business
partners or trusted bulk sending services. Although it is not
practical for each recipient to accredit every sender, the definition
of core networks of explicit trust can be quite useful.
7.2.1. Third-party Reputation and Accreditation Services
For scaling efficiency, it is appealing to use Trusted Third Party
reputation and accreditation services, to allow an email sender to
obtain a single assessment that is then recognized by every email
recipient that recognizes the Trusted Third Party.
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, MUAs MAY also support DKIM
support signing and verifying in MUAs. signing and verifying directly.
DKIM requires that all verifiers treat messages with signatures that Outbound: An MUA MAY support signing even if mail is to be
do not verify as if they are unsigned. If verification in the client relayed through an outbound MSA. In this case the signature
is to be acceptable to users, it is also essential that successful applied by the MUA will be in addition to any signature added
verification of a signature not result in a less than satisfactory by the MSA.
user experience compared to leaving the message unsigned.
7.4. Per user signatures Some user software goes beyond simple user functionality and
also perform MSA and MTA functions. When this is employed for
sending directly to a receiving ADMD, the user software SHOULD
be considered an outbound MTA.
Although DKIM's use of domain names is optimized for a scope of Inbound: An MUA MAY rely on a report of a DKIM signature
organization-level signing, it is possible to administer sub-domains verification that took place at some point in the inbound MTA/
and/or selectors in a way that supports per-user signing. MDA path (e.g., an Authentication-Results header field), or an
MUA MAY perform DKIM signature verification directly. A
verifying MUA SHOULD allow for the case where mail has modified
in the inbound MTA path; if a signature fails, the message
SHOULD NOT be treated any different than if it did not have a
signature.
NOTE: As stated earlier, it is important to distinguish between the An MUA that looks for an Authentication-Results header field
use of selectors for differential administration of keys, versus MUST be configurable to choose which Authentication-Results are
the use of sub-domains for differential reputations. It's also considered trustable.
probably a good idea to note that receivers are unlikely to pay
attention to reputation at a user granularity even if it's
technically feasible to publish it.
As a constraint on an authorized DKIM signing agent, its associated DKIM requires that all verifiers treat messages with signatures
key record can specify restrictions on the email addresses permitted that do not verify as if they are unsigned.
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
bulk marketing communications without the risk of effectively
delegating the authority to sign messages purporting to come from the
domain-owning organization's CEO.
NOTE: Any scheme that involves maintenance of a significant number If verification in the client is to be acceptable to users, it
of public keys is likely to require infrastructure enhancements, is essential that successful verification of a signature not
to support that management. For example, a system in which the result in a less than satisfactory user experience compared to
end user is required to generate a public key pair and transmit it leaving the message unsigned. The mere presence of a verified
to the DNS administrator out of band is not likely to meet DKIM signature MUST NOT by itself be used by an MUA to indicate
acceptance criteria for either usability or security. that a message is to be treated better than a message without a
verified DKIM signature. However, the fact that a DKIM
signature was verified MAY be used as input into a reputation
system (i.e., a whitelist of domains and users) for
presentation of such indicators.
8. Security Considerations It is common for components of an ADMD's email infrastructure to do
violence to a message, such that a DKIM signature might be rendered
invalid. Hence, users of MUAs that support DKIM signing and/or
verifying need a basis for knowing that their associated email
infrastructure will not break a signature.
TBD 9. Other Considerations
9. IANA Considerations 9.1. Security Considerations
TBD The security considerations of the DKIM protocol are described in the
DKIM base specification [RFC4871].
9.2. IANA Considerations
This document has no considerations for IANA.
10. Acknowledgements 10. Acknowledgements
TBD TBD
11. Informative References 11. Informative References
[I-D.ietf-dkim-overview]
Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview",
draft-ietf-dkim-overview-10 (work in progress), July 2008.
[I-D.ietf-dkim-ssp]
Local-part, a., Domain, A., error, r., Allman, E., Fenton,
J., Delany, M., and J. Levine, "DomainKeys Identified Mail
(DKIM) Author Domain Signing Practices (ADSP)",
draft-ietf-dkim-ssp-09 (work in progress), February 2009.
[I-D.ietf-openpgp-rfc2440bis] [I-D.ietf-openpgp-rfc2440bis]
Callas, J., "OpenPGP Message Format", Callas, J., "OpenPGP Message Format",
draft-ietf-openpgp-rfc2440bis-22 (work in progress), draft-ietf-openpgp-rfc2440bis-22 (work in progress),
April 2007. April 2007.
[I-D.kucherawy-sender-auth-header] [I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", Message Authentication Status",
draft-kucherawy-sender-auth-header-17 (work in progress), draft-kucherawy-sender-auth-header-20 (work in progress),
October 2008. January 2009.
[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", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. 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, [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998. "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
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, [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001. 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.
skipping to change at page 22, line 5 skipping to change at page 36, line 45
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using [RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
May 2007. May 2007.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Appendix A. Migrating from DomainKeys
As with any migration, the steps required will be determined by who
is doing the migration and their assessment of
o the users of what they are generating, or
o the providers of what they are consuming.
A.1. Signers
A signer that currently signs with DomainKeys (DK) will go through
various stages as they migrate to using DKIM, not all of which are
required for all signers. The real questions that a signer must ask
are:
1. how many receivers or what types of receivers are *only* looking
at the DK signatures and not the DKIM signatures,
2. and how much does the signer care about those receivers?
If no one is looking at the DK signature any more, then it's no
longer necessary to sign with DK. Or if there are no more "large
players" looking only at the DK signatures, a signer may choose to
stop signing with DK.
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. In particular, the same selectors and DNS Key
Records may be used for both, after verifying that they are
compatible as discussed below.
Each secondary step in all of the following scenarios is to be
prefaced with the gating factor "test, then when comfortable with the
previous step's results, continue".
One migration strategy is to:
o ensure that the current selector DNS key record is compatible with
both DK and DKIM
o sign messages with both DK and DKIM signatures
o when it's decided that DK signatures are no longer necessary, stop
signing with DK
Another migration strategy is to:
o add a new selector DNS key record only for DKIM signatures
o sign messages with both DK (using the old DNS key record) and DKIM
signatures (using the new DNS key record)
o when it's decided that DK signatures are no longer necessary, stop
signing with DK
o eventually remove the old DK selector DNS record
A combined migration strategy is to:
o ensure that the current selector DNS key record is compatible with
both DK and DKIM
o start signing messages with both DK and DKIM signatures
o add a new selector DNS key record for DKIM signatures
o switch the DKIM signatures to use the new selector
o when it's decided that DK signatures are no longer necessary, stop
signing with DK
o eventually remove the old DK selector DNS record
Another migration strategy is to:
o add a new selector DNS key record for DKIM signatures
o do a flash cut and replace the DK signatures with DKIM signatures
o eventually remove the old DK selector DNS record
Another migration strategy is to:
o ensure that the current selector DNS key record is compatible with
both DK and DKIM
o do a flash cut and replace the DK signatures with DKIM signatures
Note that when you have separate key records for DK and DKIM, you can
use the same public key for both.
A.1.1. DNS Selector Key Records
The first step in some of the above scenarios is ensuring that the
selector DNS key records are compatible for both DK and DKIM. The
format of the DNS key record was intentionally meant to be backwardly
compatible between the two systems, but not necessarily upwardly
compatible. DKIM has enhanced the DK DNS key record format by adding
several optional parameters, which DK must ignore. However, there is
one critical difference between DK and DKIM DNS key records: the
definitions of the g fields:
g= granularity of the key In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. DKIM allows wildcards where
DK does not. For DK, an empty field is the same as a missing
value, and is treated as allowing any sending address. For DKIM,
an empty field only matches an empty local part. In DKIM, both a
missing value and "g=*;" mean to allow any sending address.
If your DK DNS key record has an empty g= field in it ("g=;"),
your best course of action is to modify the record to remove the
empty field. In that way, the DK semantics will remain the same,
and the DKIM semantics will match.
If your DNS key record does not have an empty g= field in it ("g=;"),
it's probable that the record can be left alone. But your best
course of action would still be to make sure it has a v= field. When
the decision is made to stop supporting DomainKeys and to only
support DKIM, you MUST verify that the "g" field is compatible with
DKIM, and it SHOULD have "v=DKIM1;" in it. It is highly RECOMMENDED
that if you want to use an empty g= field in your DKIM selector, you
also include the v= field.
A.1.2. Removing DomainKeys Signatures
The principal use of DomainKeys is at Boundary MTAs. Because no
operational transition is ever instantaneous, it is advisable to
continue performing DomainKeys signing until it is determined that
DomainKeys receive-side support is no longer used, or is sufficiently
reduced. That is, a signer SHOULD add a DKIM signature to a message
that also has a DomainKeys signature and keep it there until you
decide it can go away. The signer may do its transitions in a
straightforward manner, or more gradually. Note that because digital
signatures are not free, there is a cost to performing both signing
algorithms, so you don't want to be signing with both algorithms for
too long a period.
The tricky part is deciding when DK signatures are no longer
necessary. The real questions are: how many DomainKeys verifiers are
there that do *not* also do DKIM verification, which ones of them do
you care about, and how can you track their usage? Most of the early
adopters of DK verification have added DKIM verification, but not all
yet. If a verifier finds a message with both DK and DKIM, it may
choose to verify both signatures, or just one or the other.
Many DNS services offer tracking statistics so you can find out how
often a DNS record has been accessed. By using separate DNS selector
key records for your signatures, you can chart the usage of your
records over time, and watch the trends. An additional
distinguishing factor to track would take into account the verifiers
that verify both the DK and DKIM signatures, and discount those from
your counts of DK selector usage. When the number for DK selector
access reaches a low-enough level, that's the time to consider
stopping your DK signing.
Note, this level of rigor is not required. It is perfectly
reasonable for a DK signer to decide to follow the "flash cut"
scenario described above.
A.2. Verifiers
As a verifier, you are faced with several issues:
A.2.1. Do you verify DK signatures?
At the time of writing, there is still a significant number of sites
that are only producing DK signatures. Over time, it is expected
that this number will go to zero, but it may take several years. So
it would be prudent for the foreseeable future for a verifier to look
for and verify both DKIM and DK signatures.
A.2.2. Do you verify both DK and DKIM signatures within a single
message?
For a period of time, there will be sites that sign with both DK and
DKIM. A verifier receiving a message that has both types of
signatures may verify both signatures, or just one. One disadvantage
of verifying both signatures is that signers will have a more
difficult time deciding how many verifiers are still using their DK
selectors. One transition strategy is to verify the DKIM signature,
then only verify the DK signature if the DKIM verification fails.
A.2.3. DNS Selector Key Records
The format of the DNS key record was intentionally meant to be
backwardly compatible between DK and DKIM, but not necessarily
upwardly compatible. DKIM has enhanced the DK DNS key record format
by adding several optional parameters, which DK must ignore.
However, there is one key difference between DK and DKIM DNS key
records: the definitions of the g fields:
g= granularity of the key In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. For DK, an empty field is
the same as a missing value, and is treated as allowing any
sending address. For DKIM, an empty field only matches an empty
local part.
v= version of the selector It is recommended that a DKIM selector
have v=DKIM1; at its beginning, but it is not required.
If a DKIM verifier finds a selector record that has an empty g= field
("g=;") and it does not have a v= field ("v=DKIM1;") at its
beginning, it is faced with deciding if this record was
1. from a DK signer that transitioned to supporting DKIM but forgot
to remove the g= field (so that it could be used by both DK and
DKIM verifiers), or
2. from a DKIM signer that truly meant to use the empty g= field but
forgot to put in the v= field. It is RECOMMENDED that you treat
such records using the first interpretation, and treat such
records as if the signer did not have a g= field in the record.
Appendix B. General Coding Criteria for Cryptographic Applications
NOTE: This section could possibly be changed into a reference to
something else, such as another rfc.
Correct implementation of a cryptographic algorithm is a necessary
but not a sufficient condition for the coding of cryptographic
applications. Coding of cryptographic libraries requires close
attention to security considerations that are unique to cryptographic
applications.
In addition to the usual security coding considerations, such as
avoiding buffer or integer overflow and underflow, implementers
should pay close attention to management of cryptographic private
keys and session keys, ensuring that these are correctly initialized
and disposed of.
Operating system mechanisms that permit the confidentiality of
private keys to be protected against other processes should be used
when available. In particular, great care must be taken when
releasing memory pages to the operating system to ensure that private
key information is not disclosed to other processes.
Certain implementations of public key algorithms such as RSA may be
vulnerable to a timing analysis attack.
Support for cryptographic hardware providing key management
capabilities is strongly encouraged. In addition to offering
performance benefits, many cryptographic hardware devices provide
robust and verifiable management of private keys.
Fortunately appropriately designed and coded cryptographic libraries
are available for most operating system platforms under license terms
compatible with commercial, open source and free software license
terms. Use of standard cryptographic libraries is strongly
encouraged. These have been extensively tested, reduce development
time and support a wide range of cryptographic hardware.
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave. South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+dkimov@maillennium.att.com Email: tony+dkimov@maillennium.att.com
Ellen Siegel
Constant Contact, Inc.
1601 Trapelo Rd, Ste 329
Waltham, MA 02451
USA
Email: esiegel@constantcontact.com
Phillip Hallam-Baker Phillip Hallam-Baker
VeriSign Inc. VeriSign Inc.
Email: pbaker@verisign.com Email: pbaker@verisign.com
Dave Crocker Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Ellen Siegel
Constant Contact, Inc.
1601 Trapelo Rd, Ste 329
Waltham, MA 02451
USA
Email: esiegel@constantcontact.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 178 change blocks. 
648 lines changed or deleted 1576 lines changed or added

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