draft-ietf-dkim-overview-05.txt   draft-ietf-dkim-overview-06.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational D. Crocker Intended status: Informational D. Crocker
Expires: December 13, 2007 Brandenburg InternetWorking Expires: May 14, 2008 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
June 11, 2007 November 11, 2007
DomainKeys Identified Mail (DKIM) Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-05 draft-ietf-dkim-overview-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2007. This Internet-Draft will expire on May 14, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) allows an organization to take
with a message and provides a means of verifying that the association responsibility for a message, in a way that can be validated by a
is legitimate. [RFC4871] DKIM defines a domain-level authentication recipient. The organization can be the author's, the originating
framework for email using public-key cryptography and key server sending site, an intermediary, or one of their agent's. DKIM defines
technology. This permits verifying the source or intermediary for a a domain-level digital signature authentication framework for email,
message, as well as the contents of messages. The ultimate goal of using public-key cryptography and key server technology. This
this framework is to permit a signing domain to assert responsibility permits verifying the signer of a message, as well as the integrity
for a message, thus proving and protecting the identity associated of its contents. The ultimate goal of this framework is to permit a
with the message and the integrity of the messages itself, while signing domain to assert responsibility for a message, thus proving
retaining the functionality of Internet email as it is known today. and protecting the identity associated with the message and the
Such protection of email identity may assist in the global control of integrity of the messages itself, while retaining the functionality
"spam" and "phishing". This document provides an overview of DKIM, of Internet email as it is known today. Such protection of email
describes how it can fit into a messaging service, describes how it identity can assist in the global control of "spam" and "phishing".
relates to other IETF message signature technologies, and includes This document provides an overview of the DKIM service and describes
implementation and migration considerations. how it can fit into a messaging service. It also describes how DKIM
relates to other IETF message signature technologies.
Table of Contents Table of Contents
1. DKIM Framework . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5
1.3. Function . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Internet Mail Background . . . . . . . . . . . . . . . . . . . 5
1.4. Service Architecture . . . . . . . . . . . . . . . . . . . 13 2.1. Administrative Management Domain (ADMD) . . . . . . . . . 6
2. Deployment and Operation of DKIM Base . . . . . . . . . . . . 15 2.2. DKIM Placement within an ADMD . . . . . . . . . . . . . . 8
2.1. Development . . . . . . . . . . . . . . . . . . . . . . . 15 3. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8
2.2. Email Infrastructure Agents . . . . . . . . . . . . . . . 16 4. The Role of Trust . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 17 5. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10
2.5. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11
2.6. On-going Operations . . . . . . . . . . . . . . . . . . . 24 6. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. The Basic Signing Service . . . . . . . . . . . . . . . . 13
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Characteristics of a DKIM signature . . . . . . . . . . . 13
4. Informative References . . . . . . . . . . . . . . . . . . . . 29 6.3. The Selector construct . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 32 7. Service Architecture . . . . . . . . . . . . . . . . . . . . . 14
7.1. Administration and Maintenance . . . . . . . . . . . . . . 16
1. DKIM Framework 7.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 17
7.5. Evaluating . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1.1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) allows an organization to take
with a message and provides a means of verifying that the association responsibility for a message, in a way that can be validated by a
is legitimate. [RFC4871] DKIM accomplishes this by defining a recipient. The organization can be the author's, the originating
domain-level authentication framework for email using public-key sending site, an intermediary, or one of their agent's. DKIM defines
cryptography and key server technology. This permits verifying the a domain-level digital signature authentication framework for email,
source or intermediary for a message, as well as the contents of using public-key cryptography and key server technology. This
messages. DKIM will also provide a mechanism that permits potential permits verifying the signer of a message, as well as the integrity
email signers to publish information about their email signing of its contents. DKIM accomplishes this by defining a domain-level
practices; this will permit email receivers to make additional authentication framework for email using public-key cryptography and
assessments of unsigned messages. key server technology [RFC4871]. This permits verifying a message
source, an intermediary, or one of their agents, as well as the
integrity of its contents. DKIM will also provide a mechanism that
permits potential email signers to publish information about their
email signing practices; this will permit email receivers to make
additional assessments of unsigned messages.
The ultimate goal of this framework is to permit a domain to assert The ultimate goal of this framework is to permit a domain to assert
responsibility for a message, thus proving and protecting the responsibility for a message, thus proving and protecting the
identity associated with the message and the integrity of the identity associated with the message and the integrity of the
messages itself, while retaining the functionality of Internet email messages itself, while retaining the functionality of Internet email
as it is known today. Such protection of email identity, may assist as it is known today. Such protection of email identity, can assist
in the global control of "spam" and "phishing". in the global control of "spam" and "phishing".
This document provides a description of DKIM's architecture, This document provides a description of DKIM's architecture and
functionality, deployment and use. It is intended for those who are functionality. It is intended for those who are adopting,
adopting, developing, or deploying DKIM. It also will be helpful for developing, or deploying DKIM. It also will be helpful for those who
those who are considering extending DKIM, either into other areas of are considering extending DKIM, either into other areas of use or to
use or to support additional features. This Overview does not support additional features. This Overview does not provide
provide information on threats to DKIM or email, or details on the information on threats to DKIM or email, or details on the protocol
protocol specifics, which can be found in [RFC4871] and [RFC4686], specifics, which can be found in [RFC4871] and [RFC4686],
respectively. The document assumes a background in basic network respectively. The document assumes a background in basic network
security technology and services. security technology and services.
It must be stressed that neither this document nor DKIM attempt to Neither this document nor DKIM attempt to provide solutions to the
provide solutions to the world's problems with spam, phish, virii, world's problems with spam, phishing, virii, worms, joe jobs, etc.
worms, joe jobs, etc. DKIM provides one basic tool, in what needs to DKIM provides one basic tool, in what needs to be a large arsenal,
be a large arsenal, for improving the safety of Internet mail. for improving basic trust in the Internet mail service. However by
However, by itself, DKIM is not sufficient to that task and this itself, DKIM is not sufficient to that task and this Overview does
overview does not pursue the issues of integrating DKIM into these not pursue the issues of integrating DKIM into these larger efforts,
larger efforts. Rather, it is a basic introduction to the technology beyond a simple reference within a system diagram. Rather, it is a
and its deployment. basic introduction to the technology and its use.
1.1.1. The DKIM Value Proposition
The nature and origins of a message are often falsely stated. As a
foundation for distinguishing legitimate mail, DKIM provides a means
of associating a verifiable identity with a message. Given the
presence of that identity, a receiver can make decisions about
further handling of the message, based upon assessments of that
identity.
Receivers who successfully verify a signature can use information
about the signer as part of a program to limit spam, spoofing,
phishing, or other undesirable behavior. DKIM does not, itself,
prescribe any specific actions by the recipient; rather it is an
enabling technology for services that do.
These services will typically:
1. Verify an identity
2. Determine whether the identity is known or unknown
3. Determine whether a known identity is trusted
An attack is made against an organization or against customers of an
organization. The name of the organization is linked to particular
Internet domain names. One point of leverage used by attackers is
either to spoof a legitimate domain name, or to use a "cousin" name
that is similar to one that is legitimate, but is not controlled by
the target organization. A DKIM-based accreditation service can
enforce a basic separation between domains used by such known
organizations and domains used by others.
DKIM signatures can be created by a direct handler of a message,
either as its originator or as an intermediary. It can also be
created by an independent service, providing assistance to a handler
of the message. Whoever does the signing chooses the domain name to
be used as the basis for later assessments. Hence, reputation
associated with that domain name is the basis for evaluating whether
to trust the message for delivery. The owner of the domain name
being used for a DKIM signature is declaring that they are
accountable for the message.
DKIM is intended to be a value-added feature for email. Mail that is
not signed by email is handled in the same way as it now is; it
continues to be evaluated by established analysis and filtering
techniques. Over time, widespread DKIM adoption could permit
degraded handling of messages that are not signed. However early
benefits do not require this more-stringent enforcement.
It is important to be clear about the narrow scope of DKIM's
capabilities. It is an enabling technology, intended for use in the
larger context of determining message legitimacy. This larger
context is complex, so that it is easy to assume that a component
like DKIM, which actually provides only a limited service, instead
satisfies the broader set of requirements. A DKIM signature :
o Does not offer any assertions about the behaviors of the identity
doing the signing.
o Does not prescribe any specific actions for receivers to take upon
successful (or unsuccessful) signature verification.
o Does not provide protection after signature verification.
o Does not protect against re-sending (replay of) a message that
already has a verified signature; therefore a transit intermediary
or a recipient can re-post the message in such a way that the
signature would remain verifiable, although the new recipient(s)
would not have been specified by the originator.
1.1.2. Prior Work 1.1. Prior Work
Historical email assessment based on identity has been based on the Historical email assessment based on identity has been based on the
IP Address of a system that sent the message. The Address is IP Address of a system that sent the message. The Address is
obtained via underlying Internet information mechanisms and is obtained via underlying Internet information mechanisms and is
therefore trusted to be accurate. Besides having some known security therefore trusted to be accurate. Besides having some known security
weaknesses, the use of Addresses present a number of functional and weaknesses, the use of Addresses present a number of functional and
operational problems. Consequently there is an industry desire to operational problems. Consequently there is an industry desire to
use a more stable value that has had better correspondence with use a more stable value that has better correspondence to
organizational boundaries. Domain Names are viewed as satisfying organizational boundaries. Domain Names are viewed as satisfying
this need. this need.
There have been four previous efforts at standardizing an Internet There have been four previous efforts at standardizing an Internet
email signature scheme: email signature scheme:
o Privacy Enhanced Mail (PEM) was first published in 1987. o Privacy Enhanced Mail (PEM) was first published in 1987.
[RFC0989] [RFC0989]
o PEM eventually transformed into MIME Object Security Services in o PEM eventually transformed into MIME Object Security Services
1995. [RFC1848] Today, these two are only of historical interest. (MOSS) in 1995. [RFC1848] Today, these two are only of historical
interest.
o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
first released in 1991. [RFC1991] A later version was first released in 1991. [RFC1991] A later version was
standardized as OpenPGP. [RFC2440] [RFC3156] standardized as OpenPGP. [RFC2440] [RFC3156]
[I-D.ietf-openpgp-rfc2440bis] [I-D.ietf-openpgp-rfc2440bis]
o RSA Security independently developed Secure MIME (S/MIME) to o RSA Security independently developed Secure MIME (S/MIME) to
transport a PKCS #7 data object. [RFC3851] transport a PKCS #7 data object. [RFC3851]
Development of S/MIME and OpenPGP have continued. While both have Development of S/MIME and OpenPGP have continued. While both have
skipping to change at page 6, line 21 skipping to change at page 5, line 4
keys. It uses a key-centric Public Key Infrastructure (PKI) rather keys. It uses a key-centric Public Key Infrastructure (PKI) rather
than the more typical approaches based on a certificate in the styles than the more typical approaches based on a certificate in the styles
of Kohnfelder (X.509) or Zimmermann (web of trust). For DKIM, the of Kohnfelder (X.509) or Zimmermann (web of trust). For DKIM, the
owner of a key asserts its validity, rather than relying on the key owner of a key asserts its validity, rather than relying on the key
having a broader semantic implication of the assertion, such as a having a broader semantic implication of the assertion, such as a
quality assessment of the key's owner. DKIM treats quality quality assessment of the key's owner. DKIM treats quality
assessment as an independent, value-added service, beyond the initial assessment as an independent, value-added service, beyond the initial
work of deploying a verifying signature service. work of deploying a verifying signature service.
Further, DKIM's PKI is supported by adding additional information Further, DKIM's PKI is supported by adding additional information
records to the existing Domain Name Service (DNS) [RFC1034], rather records to the existing Domain Name System (DNS) [RFC1034], rather
than requiring deployment of a new query infrastructure. This than requiring deployment of a new query infrastructure. This
approach has significant operational advantages. First, it avoids approach has significant operational advantages. First, it avoids
the considerable barrier of creating a new infrastructure; hence it the considerable barrier of creating a new infrastructure; hence it
leverages a global base of administrative experience and highly leverages a global base of administrative experience and highly
reliable distributed operation. Second, the technical aspect of the reliable distributed operation. Second, the technical aspect of the
DNS is already known to be efficient. Any new service would have to DNS is already known to be efficient. Any new service would have to
undergo a period of gradual maturation, with potentially problematic undergo a period of gradual maturation, with potentially problematic
early-stage behaviors. By (re-)using the DNS, DKIM avoids these early-stage behaviors. By (re-)using the DNS, DKIM avoids these
growing pains. growing pains.
1.1.3. Internet Mail Background 1.2. Discussion Venue
NOTE TO RFC EDITOR: This "Discussion Venue" section is to be
removed prior to publication.
This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org.
2. Internet Mail Background
Internet Mail has a simple split between the user world, in the form Internet Mail has a simple split between the user world, in the form
of Mail User Agents (MUA), and the transmission world, in the form of of Mail User Agents (MUA), and the transmission world, in the form of
the Mail Handling Service (MHS) composed of Mail Transfer Agents the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User (MTA). The MHS is responsible for accepting a message from one user,
and delivering it to one or more other users, creating a virtual MUA- the author, and delivering it to one or more other users, the
to-MUA exchange environment. The first MTA is called the Mail recipients. This creates a virtual MUA-to-MUA exchange environment.
Submission Agent (MSA) and the final MTA is called the Mail Delivery The first component of the MHS is called the Mail Submission Agent
Agent (MDA). (MSA) and the last is called the Mail Delivery Agent (MDA).
Modern Internet Mail service is marked by many independent operators, An email Mediator is both an inbound MDA and outbound MSA. It takes
many different components for providing users with service and many delivery of a message and reposts it for further distribution,
other components for performing message transfer. Consequently, it retaining the original From header field. A mailing list is a common
is necessary to distinguish administrative boundaries that surround example of a Mediator
sets of functional components.
1.1.3.1. Administrative Actors The modern Internet Mail service is marked by many independent
operators, many different components for providing users with service
and many other components for performing message transfer.
Consequently, it is necessary to distinguish administrative
boundaries that surround sets of functional components, which are
subject to coherent operational policies.
As expanded on below, every MSA is a candidate for signing using
DKIM, and every MDA is a candidate for doing DKIM verification.
2.1. Administrative Management Domain (ADMD)
Operation of Internet Mail services is apportioned to different Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). An ADMD operates with an ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust. Examples include: an end- to differing types and amounts of trust. Examples include: an end-
user operating their desktop client that connects to an independent user operating their desktop client that connects to an independent
email service, a department operating a submission agent or a local email service, a department operating a submission agent or a local
Relay, an organization's IT group that operates enterprise Relays, Relay, an organization's IT group that operates enterprise Relays,
and an ISP operating a public shared email service. and an ISP operating a public shared email service.
Each of these can be configured into many combinations of Each of these can be configured into many combinations of
administrative and operational relationships, with each ADMD administrative and operational relationships, with each ADMD
potentially having a complex arrangement of functional components. potentially having a complex arrangement of functional components.
Figure 1 depicts the relationships among ADMDs. Perhaps the most Figure 1 depicts the relationships among ADMDs. Perhaps the most
salient aspect of an ADMD is the differential trust that determines salient aspect of an ADMD is the differential trust that determines
its policies for activities within the ADMD, versus those involving its policies for activities within the ADMD, versus those involving
interactions with other ADMDs. interactions with other ADMDs.
Basic components of ADMD distinction include: Basic types of ADMDs include:
Edge: Independent transfer services, in networks at the edge of Edge: Independent transfer services, in networks at the edge of
the Internet Mail service. the Internet Mail service.
User: End-user services. These might be subsumed under an Edge User: End-user services. These might be subsumed under an Edge
service, such as is common for web-based email access. service, such as is common for web-based email access.
Transit: These are Mail Service Providers (MSP) offering value- Transit: These are Mail Service Providers (MSP) offering value-
added capabilities for Edge ADMDs, such as aggregation and added capabilities for Edge ADMDs, such as aggregation and
filtering. filtering.
Note that Transit services are quite different from packet-level Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level. is often directly between the Edge ADMDs, at the email level.
+-------+ +-------+ +-------+ +--------+ +--------+ +--------+
| ADMD1 | | ADMD3 | | ADMD4 | | ADMD#1 | | ADMD#3 | | ADMD#4 |
| ----- | | ----- | | ----- | | ------ | | ------ | | ------ |
| | +---------------------->| | | | | | +----------------------->| | | |
| User | | |-Edge--+--->|-User | | User | | |--Edge--+--->|--User |
| | | | +--->| | | | | | | | +--->| | | |
| V | | | +-------+ +-------+ | V | | | +--------+ +--------+
| Edge--+---+ | | Edge---+---+ |
| | | +---------+ | | | | +----------+ |
+-------+ | | ADMD2 | | +--------+ | | ADMD#2 | |
| | ----- | | | | ------ | |
| | | | | | | |
+--->|-Transit-+---+ +--->|-Transit--+---+
| | | |
+---------+ +----------+
Figure 1: ADministrative Management Domains (ADMD) Example Figure 1: ADministrative Management Domains (ADMD) Example
In Figure 1, ADMD numbers 1 and 2 are candidates for doing DKIM
signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM
verification.
The distinction between Transit network and Edge network transfer The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for services is primarily significant because it highlights the need for
concern over interaction and protection between independent concern over interaction and protection between independent
administrations. The interactions between functional components administrations. The interactions between functional components
within an ADMD are subject to the policies of that domain. within an ADMD are subject to the policies of that domain.
Common ADMD examples are: Common ADMD examples are:
Enterprise Service Providers: Operators of an organization's Enterprise Service Providers:
internal data and/or mail services.
Internet Service Providers: Operators of underlying data Operators of an organization's internal data and/or mail
communication services that, in turn, are used by one or more services.
Relays and Users. It is not necessarily their job to perform
email functions, but they can, instead, provide an environment
in which those functions can be performed.
Mail Service Providers: Operators of email services, such as for Internet Service Providers:
end-users, or mailing lists.
1.1.4. Conventions Operators of underlying data communication services that, in
turn, are used by one or more Relays and Users. It is not
necessarily their job to perform email functions, but they
can, instead, provide an environment in which those
functions can be performed.
In this document, references to structured fields of a message use a Mail Service Providers:
two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name
of the field. Hence <RFC2822.From> is the From field in an email
content header [RFC2822] and <RFC2821.MailFrom> is the address in the
SMTP "Mail From" command. [RFC2821]
This document is being discussed on the DKIM mailing list, Operators of email services, such as for end-users, or
ietf-dkim@mipassoc.org. mailing lists.
1.2. Goals 2.2. DKIM Placement within an ADMD
DKIM seeks to add authentication to the existing email transfer It is expected that the most common venue for a DKIM implementation
infrastructure. This motivates functional goals about authentication will be within the infrastructures of the originating organization's
and operational goals about integration with the existing email outbound service and and the receiving organization's inbound
service. service, such as a department or a boundary MTA. DKIM can be
implemented in an author's or recipient MUA, but this is expected to
be less typical, since it has higher administration and support
costs.
1.2.1. Functional A Mediator, such as a mailing list, often can re-post a message
without breaking the DKIM signature. Furthermore it can add its own
signature. This can be added by the Mediator software itself, or by
any outbound component in the Mediator's ADMD.
Use Domain-level granularity for assurance. OpenPGP and S/MIME 3. The DKIM Value Proposition
apply the end-to-end principle in terms of individual originators
and recipients, notably using full email addresses. DKIM seeks
accountability at the more coarse grain of an organization or,
perhaps, a department. A deployed construct that enables this
granularity is the domain name, to which the signing key record is
bound. Further DKIM signing and/or validating may be implemented
anywhere along the transit path, rather than only in the end
systems.
Allow delegation of signing to independent parties. Different The nature and origins of a message are often falsely stated. As a
parties have different roles in the process of email exchange. foundation for distinguishing legitimate mail, DKIM provides a means
Some of these parties are easily visible to end users and others of associating a verifiable identity with a message. Given the
are primarily visible to operators of the service. DKIM needs to presence of that identity, a receiver can make decisions about
support signing by any of these different parties and needs to further handling of the message, based upon assessments of that
permit them to sign with any domain name that they deem identity.
appropriate. As an example an organization that creates email
content often delegates portions of its processing or transmission
to an outsourced group. DKIM must support this mode of activity,
in a manner that is not visible to end users.
Distinguish the core authentication mechanism from its derivative Receivers who successfully verify a signature can use information
uses. An authenticated identity may be subject to a variety of about the signer as part of a program to limit spam, spoofing,
processing policies, either ad hoc or standardized. The only phishing, or other undesirable behavior. DKIM does not, itself,
semantics inherent to a DKIM signature is that the signer is prescribe any specific actions by the recipient; rather it is an
asserting (some) responsibility for the message. All other enabling technology for services that do.
mechanisms and meanings are independent of this core service. One
such mechanism might assert a relationship between the signing
identity and the author (<RFC2822.From>) domain identity. Another
might specify how to treat an unsigned message with that
<RFC2822.From> domain.
Retain ability to have anonymous email. The ability to send a These services will typically:
message that does not identify its author is considered to be a
valuable quality of the current email system that needs to be
retained. DKIM is compatible with this goal since it permits an
email system operator to be authenticated, rather than the content
author. Knowing that a mail definitely came from example.com does
not threaten the anonymity of the user, if it is still possible to
obtain effectively anonymous accounts at example.com and other
mail providers.
1.2.2. Operational 1. Verify an identity
Make signature transparent to non-supporting recipients. S/MIME and 2. Determine whether the identity is known or unknown
OpenPGP both modify the message body. Hence, their presence is
potentially visible to email recipients and their user software 3. Determine whether a known identity is trusted
must be able to process the associated constructs. In order to
facilitate incremental adoption, DKIM is designed to be The role of DKIM is in the first two of these; DKIM is an enabler for
transparent to recipients that do not support it. the third.
An attack is made against an organization or against customers of an
organization. The name of the organization is linked to particular
Internet domain names. One point of leverage used by attackers is
either to spoof a legitimate domain name, or to use a "cousin" name
that is similar to one that is legitimate, but is not controlled by
the target organization. A DKIM-based accreditation service can
enforce a basic separation between domains used by such known
organizations and domains used by others.
DKIM signatures can be created by a direct handler of a message,
either as its originator or as an intermediary. It can also be
created by an independent service, providing assistance to a handler
of the message. Whoever does the signing chooses the domain name to
be used as the basis for later assessments. Hence, reputation
associated with that domain name is the basis for evaluating whether
to trust the message for delivery. The owner of the domain name
being used for a DKIM signature is declaring that they are
accountable for the message.
DKIM is intended to be a value-added feature for email. Mail that is
not signed by DKIM is handled in the same way as it was, before DKIM
was defined; it continues to be evaluated by established analysis and
filtering techniques. Over time, widespread DKIM adoption could
permit more strict handling of messages that are not signed. However
early benefits do not require this and probably do not warrant this.
It is important to be clear about the narrow scope of DKIM's
capabilities. It is an enabling technology, intended for use in the
larger context of determining message legitimacy. This larger
context is complex, so that it is easy to assume that a component
like DKIM, which actually provides only a limited service, instead
satisfies the broader set of requirements. A DKIM signature:
o Does not offer any assertions about the behaviors of the identity
doing the signing.
o Does not prescribe any specific actions for receivers to take upon
successful signature verification.
o Does not provide protection after signature verification.
o Does not protect against re-sending (replay of) a message that
already has a verified signature; therefore a transit intermediary
or a recipient can re-post the message in such a way that the
signature would remain verifiable, although the new recipient(s)
would not have been specified by the author.
4. The Role of Trust
As mentioned above, DKIM lets you verify the identity of a signer and
is an enabler for determining whether a now-known identity is
trusted; it does not itself provide that determination. Deciding
whether a non-known identity can be trusted must be handled by
accreditation and reputation services that are themselves trustable.
An accreditation service provides an assessment of a sender's
trustworthiness on behalf of the sender. They reflect the statement
"this signer says they are good and I concur with that statement."
Accreditation services are almost always network-based.
A reputation service provides an assessment of a sender's
trustworthiness on behalf of the receiver. They reflect the
statements "based on their past history or some private knowledge
about them, this signer can be trusted" or "not trusted." Reputation
services can be network-based or be based on local white lists and
black lists.
5. DKIM Goals
DKIM adds an end-to-end authentication mechanism to the existing
email transfer infrastructure. This motivates functional goals about
authentication and operational goals about integration with the
existing email service.
5.1. Functional Goals
5.1.1. Use Domain-level granularity for assurance.
OpenPGP and S/MIME apply the end-to-end principle in terms of
individual originators and recipients, notably using full email
addresses. DKIM seeks accountability at the more coarse granularity
of an organization or, perhaps, a department. An existing Internet
service construct that enables this granularity is the Domain Name
[RFC1034], to which the signing key record is bound. Further DKIM
signing and/or validating can be implemented anywhere along the
transit path, rather than only in the end systems or only in the
boundary MTA.
5.1.2. Allow delegation of signing to independent parties.
Different parties have different roles in the process of email
exchange. Some are easily visible to end users and others are
primarily visible to operators of the service. DKIM needs to support
signing by any of these different parties and needs to permit them to
sign with any domain name that they deem appropriate (and for which
they are authorized.) As an example an organization that creates
email content often delegates portions of its processing or
transmission to an outsourced group. DKIM supports this mode of
activity, in a manner that is not visible to end users.
5.1.3. Distinguish the core authentication mechanism from its
derivative uses.
An authenticated identity can be subject to a variety of processing
policies, either ad hoc or standardized. The only semantics inherent
to a DKIM signature is that the signer is asserting (some)
responsibility for the message. All other mechanisms and meanings
are independent of this core service. One such mechanism might
assert a relationship between the signing identity and the author, as
specified in the From header field's domain identity[RFC2822].
Another might specify how to treat an unsigned message with that From
field domain.
5.1.4. Retain ability to have anonymous email.
The ability to send a message that does not identify its author is
considered to be a valuable quality of the current email service that
needs to be retained. DKIM is compatible with this goal since it
permits an email system operator to be authenticated, rather than the
content author. Knowing that a message definitely came from
example.com does not threaten the anonymity of the user who authored
it, if it is still possible to obtain effectively anonymous accounts
at example.com.
5.2. Operational Goals
5.2.1. Treat verification failure the same as no signature present.
Treat verification failure the same as no signature unsigned.
OpenPGP and S/MIME were both designed for strong cryptographic OpenPGP and S/MIME were both designed for strong cryptographic
protection. This included treating verification failure as protection. This included treating verification failure as message
message failure. As a sub-goal to the requirement for failure. As a sub-goal to the requirement for transparency, a DKIM
transparency, a DKIM signature verifier is to treat messages with signature verifier is to treat messages with signatures that fail as
signatures that fail as if they were unsigned. Hence the message if they were unsigned. Hence the message will revert to normal
will revert to normal handling, through the receiver's existing handling, through the receiver's existing filtering mechanisms.
filtering mechanisms. Thus, a sender cannot apply a broken signture and force a message to
be treated any differently than if the signature weren't there.
Permit incremental adoption for incremental benefit. DKIM can 5.2.2. Make signatures transparent to non-supporting recipients.
immediately provide benefits between any two organizations that
exchange email and implement DKIM. In the usual manner of S/MIME and OpenPGP both modify the message body. Hence, their
"network effects", the benefits of DKIM increase dramatically as presence is potentially visible to email recipients and their user
its adoption increases. software needs to process the associated constructs. In order to
facilitate incremental adoption, DKIM is designed to be transparent
to recipients that do not support it. A DKIM signature cannot "get
in the way" for such recipients.
5.2.3. Permit incremental adoption for incremental benefit.
DKIM can immediately provide benefits between any two organizations
that exchange email and implement DKIM. In the usual manner of
"network effects", the benefits of DKIM increase dramatically as its
adoption increases.
Although it is envisioned that this mechanism will call upon Although it is envisioned that this mechanism will call upon
independent services to aid in the assessment of DKIM results, independent services to aid in the assessment of DKIM results, they
they are not essential in order to obtain an initial benefit. For are not essential in order to obtain initial benefit. For example
example DKIM allows (possibly large) pair-wise sets of email DKIM allows (possibly large) pair-wise sets of email providers and
providers and spam filtering companies to distinguish mail that is spam filtering companies to distinguish mail that is associated with
associated with a known organization, from mail that might a known organization, from mail that might deceptively purport to
deceptively purport to have the affiliation. This in turn allows have the affiliation. This in turn allows the development of
the development of 'whitelist' schemes whereby authenticated mail "whitelist" schemes whereby authenticated mail from a known source
from a known source with good reputation is allowed to bypass some with good reputation is allowed to bypass some spam filters.
spam filters. In effect the email receiver is using their set of
known relationships to generate their own accreditation/reputation
data. This works particularly well for traffic between large
sending providers and large receiving providers. However it also
works well for any operator, public or private, that has mail
traffic dominated by exchanges among a stable set of
organizations.
Minimize the amount of required infrastructure. A new service, or In effect the email receiver is using their set of known
an enhancement to an existing service, requires adoption by some relationships to generate their own reputation data. This works
number of systems, before it can be useful. The greater the particularly well for traffic between large sending providers and
number of required adopters, the higher the adoption barrier. large receiving providers. However it also works well for any
This becomes particularly serious when adoption is required by operator, public or private, that has mail traffic dominated by
intermediary -- that is, infrastructure -- service providers. In exchanges among a stable set of organizations.
order to allow early adopters to gain early benefit, DKIM seeks to
make no changes to the core Internet Mail service and, instead, to
allow a useful benefit for any signer/verifier pair of
participants exchanging mail.
Similarly, DKIM's reliance on the Domain Name Service greatly 5.2.4. Minimize the amount of required infrastructure
reduces the amount of new administrative infrastructure that must
be deployed over the open Internet.
Permit wide range of deployment choices. It should be possible to A new service, or an enhancement to an existing service, requires
implement DKIM at a variety of places within an organization's adoption by some number of systems, before it can be useful. The
email service. This permits the organization to choose how much greater the number of required adopters, the higher the adoption
or how little they want DKIM to be part of their service, rather barrier. This becomes particularly serious when adoption is required
than part of a more localized operation. by intermediary -- that is, infrastructure -- service providers. In
order to allow early adopters to gain early benefit, DKIM makes no
changes to the core Internet Mail service and, instead, can provide a
useful benefit for any signer/verifier pair of participants
exchanging mail. Similarly, DKIM's reliance on the Domain Name
System greatly reduces the amount of new administrative
infrastructure that is need, across the open Internet.
1.3. Function 5.2.5. Permit wide range of deployment choices.
DKIM can be deployed at a variety of places within an organization's
email service. This permits the organization to choose how much or
how little they want DKIM to be part of their service, rather than
part of a more localized operation.
6. DKIM Function
DKIM has a very constrained set of capabilities, primarily targeting DKIM has a very constrained set of capabilities, primarily targeting
email while it is in transit, from an originator to a set of email while it is in transit, from an author to a set of recipients.
recipients. It creates the ability to associate verifiable It creates the ability to associate verifiable information with a
information with a message, especially a responsible identity. When message, especially a responsible identity. When a message is not
a message is not signed, DKIM permits the identity of the sender to signed, DKIM permits the identity of the sender to be used for
be used for obtaining information about their signing practices. obtaining information about their signing practices.
1.3.1. The Basic Signing Service 6.1. The Basic Signing Service
With the DKIM signature mechanism, a signer associates a domain name With the DKIM signature mechanism, a signer chooses a signing
with an address, performs digital signing on the message, and records identity based on their domain name, performs digital signing on the
signature information in a DKIM header field. A verifier obtains the message, and records signature information in a DKIM header field. A
domain name from the DKIM header field, queries for a public key verifier obtains the domain name and the "selector" from the DKIM
associated with the name, and verifies the signature. header field, queries for a public key associated with the name, and
verifies the signature.
DKIM permits any domain name to be use for signing, and supports DKIM permits any domain name to be used for signing, and supports
extensible choices for various algorithms. As is typical for extensible choices for various algorithms. As is typical for
Internet standards, there is a core set of algorithms required to be Internet standards, there is a core set of algorithms that all
supported by all implementations. This ensures an initial ability to implementations are required to support, in order to guarantee basic
interoperate. interoperability. This ensures an initial ability to interoperate.
DKIM permits restricting the use of a signature key to particular DKIM permits restricting the use of a signature key to particular
types of services, such as only for email. This is helpful when types of services, such as only for email. This is helpful when
delegating signing authority, such as to a particular department or delegating signing authority, such as to a particular department or
to a third-party outsourcing service. to a third-party outsourcing service.
With DKIM the signer MUST explicitly list the headers that are With DKIM the signer explicitly lists the headers that are signed.
signed. By choosing the minimal set of headers needed the signature By choosing the minimal set of headers needed, the signature is
is likely to be considerably more robust against the handling likely to be considerably more robust against the handling the
vagaries of intermediary MTAs. vagaries of intermediary MTAs.
1.3.2. Characteristics of a DKIM signature 6.2. Characteristics of a DKIM signature
A DKIM signature covers the message body and selected header fields. A DKIM signature covers the message body and selected header fields.
The signer computes a hash of the selected header fields and another The signer computes a hash of the selected header fields and another
hash of the body. The signer then uses a private key to hash of the body. The signer then uses a private key to
cryptographically encode this information, along with other signing cryptographically encode this information, along with other signing
parameters. Signature information is placed into a new [RFC2822] parameters. Signature information is placed into a new [RFC2822]
header field of the message. header field of the message.
1.3.3. The Selector construct 6.3. The Selector construct
A signature is associated with a domain name, as specified in the A signature is associated with a domain name, as specified in the
"d=" DKIM parameter. That domain name is the complete identity used "i=" (or "d=" if "i=" is not present) DKIM-Signature header field
for making assessments about the signer. However this name is not parameters. That domain name is the complete identity used for
sufficient for making a query to obtain the key needed to verify the making assessments about the signer. However this name is not
signature. sufficient for making a DNS query to obtain the key needed to verify
the signature.
A single domain can use multiple signing keys and/or multiple A single domain can use multiple signing keys and/or multiple
signers. To support this, DKIM identifies a particular signature as signers. To support this, DKIM identifies a particular signature as
a combination of the domain name and an added field, called the a combination of the domain name and an added field, called the
"selector". Both of these are coded into the DKIM-Signature header "selector", coded into separate DKIM-Signature header field
field. parameters.
It must be stressed that the selector is not part of the domain name NOTE: The selector is not intended to be part of the domain name
that is used for making assessments. Rather, the selector is that is used for making assessments. Rather, the selector is
strictly reserved for use in administering keys that are associated strictly reserved for use in administering keys that are
with the domain name. If the selector becomes part of a name associated with the domain name. If the selector becomes part of
assessment mechanism, then there is no remaining mechanism for making a name assessment mechanism, then there is no remaining mechanism
a transition from an old, or compromised, key to a new one. for making a transition from an old, or compromised, key to a new
one.
Signers do have the need for supporting multiple assessments about Signers often need to support multiple assessments about their
their organization, such as to distinguish one type of message from organization, such as to distinguish one type of message from
another, or one portion of the organization from another. To permit another, or one portion of the organization from another. To permit
assessments that are independent, an organization should use assessments that are independent, one method is for an organization
different sub-domains in the "d=" parameter, such as to use different sub-domains in the "d=" parameter, such as
"transaction.example.com" versus "newsletter.example.com", or "transaction.example.com" versus "newsletter.example.com", or
productA.example.com versus productB.example.com. "productA.example.com" versus "productB.example.com".
1.3.4. Verification 6.4. Verification
After a message has been signed, any agent in the message transit After a message has been signed, any agent in the message transit
path can choose to verify the signature, to determine that the path can verify the signature, to determine that the signing identity
signing identity took responsibility for the message. Message took responsibility for the message. Message recipients can verify
recipients can verify the signature by querying the signer's domain the signature by querying the DNS for the signer's domain directly,
directly to retrieve the appropriate public key, and thereby confirm to retrieve the appropriate public key, and thereby confirm that the
that the message was attested to by a party in possession of the message was attested to by a party in possession of the private key
private key for the signing domain. Typically, verification will be for the signing domain. Typically, verification will be done by an
done by an agent in the ADMD of the message recipient. agent in the ADMD of the message recipient.
1.4. Service Architecture 7. Service Architecture
The DKIM service is divided into components that can be performed The DKIM service is divided into components that can be performed
using different, external services, such as for key retrieval. using different, external services, such as for key retrieval.
However the basic DKIM signing specification defines an initial set However the basic DKIM signing specification defines an initial set
of these services, in order to ensure a basic level of of these services, in order to ensure a basic level of
interoperability. interoperability.
| |
|- RFC2822 Message |- RFC2822 Message
V V
+------------------------------+ +------------------------------------+
| ORIGINATING OR RELAYING ADMD | | ORIGINATING OR RELAYING ADMD (MSA) |
| | | |
+..>| Sign Message | +..>| Sign Message |
. +--------------+---------------+ . +--------------+---------------------+
. | . |
.private | .private |
+---+---+ | +-----------+ +---+---+ |
| Key | | | Sender | | Key | | +-----------+
| Store | [Internet] | Practices | | Store | [Internet] | Sender |
+---+---+ | +-----+-----+ +---+---+ | | Practices |
.public | . .public | +-----+-----+
. V . . V .
. +------------------------------+ . . +-----------------------------------+ .
. | RELAYING OR DELIVERING ADMD | . . | RELAYING OR DELIVERING ADMD (MDA) | .
. | | . . | | .
. | Message Signed? | . . | Message Signed? | .
. +-------+----------------+-----+ . . +-------+----------------+----------+ .
. |yes |no . . |yes |no .
. V V . . V V .
. +-----------+ +-----------+ . . +-----------+ +-----------+ .
+.....>| Verify | +..>| Check |<..+ +.....>| Verify | +-->| Check |<.......+
| Signature | | | Practices | | Signature | | | Practices |<.......+
+---+-----+-+ | +---+-------+ +---+-----+-+ | +---+-------+ .
| | | | | | | | .
| +---+ | | +---+ | .
|pass fail | |pass fail | .
V | V | +-----+-----+
+--------+ | +--------+ | | Local |
+.......>| Assess | | +.......>| Assess | | | Sender |
. | Signer | | . | Signer | | | Practices |
. +---+----+ | . +---+----+ | +-----------+
. assessment| | . assessment| |
. +------+ +------+ . +------+ +------+
. | | . | |
+-+----------+ V V +-+-----------+ V V
| Reputation | +-----------+ | Reputation/ | +-----------+
+-----+------+ | Message | |Accreditation| | Message |
| Filtering | | Info | | Filtering |
| Engine | +-----+-------+ | Engine |
+-----------+> +-----------+>
Figure 2: DKIM Service Architecture Figure 2: DKIM Service Architecture
As shown in the Figure, basic message processing is divided between As shown in Figure 2, basic message processing is divided between the
signing the message, verifying the signature or determining whether a MSA and the MDA.
signature was required, and then making further decisions based upon
the results. Signing may be performed by a component of the ADMD
that creates the message, and/or within any ADMD, along the relay
path. The signer uses the appropriate private key.
Verification may be performed by any functional component along the
relay and delivery path. Verifiers retrieve the public key based
upon the parameters stored in the message. The figure shows the
verified identity as being used to assess an associated reputation,
but it could be applied for other tasks, such as management tracking
of mail.
Note that a failed signature causes the message to be treated in the
same manner as one that is unsigned. Unsigned messages prompt a
query for any published "sender practices" information, as an aid in
determining whether the sender information has been used without
authorization.
For signature verification and for the assessment of unsigned
messages, the results of these processes are treated as additional
input to the receiver's filtering engine. The engine determines
message disposition, such as whether to deliver it.
2. Deployment and Operation of DKIM Base
2.1. Development
2.1.1. Coding Criteria for Cryptographic Applications
Correct implementation of a cryptographic algorithm is a necessary
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.
On multiple processor and dual core architectures, 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.
2.1.2. Signer
Signer implementations SHOULD provide a convenient means of
generating DNS key records corresponding to the signer configuration.
Support for automatic insertion of key records into the DNS is also
highly desirable. If supported however, such mechanism(s) MUST be
properly authenticated.
A means of verifying that the signer configuration is compatible with
the signature policy is also highly desirable.
Disclosure of a private signature key component to a third party
allows that third party to impersonate the sender. The protection of
private signature key data is therefore a critical concern. Signers
SHOULD support use of cryptographic hardware providing key management
features.
The import and export of private keys, and the ability to generate a
Certificate Signing Request (CSR) for certificate registration are
highly desirable.
2.2. Email Infrastructure Agents
It is expected that the most common venue for a DKIM implementation
will be within the infrastructure of an organization's email service,
such as a department or a boundary MTA.
Outbound: An MSA or Outbound MTA should allow for the automatic
verification of the MTA configuration such that the MTA can
generate an operator alert if it determines that it is (1) an
edge MTA, and (2) configured to send email messages that do not
comply with the published DKIM sending policy.
An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to take steps
necessary to ensure that the message sent is in compliance with
the advertised email sending policy.
Inbound: An inbound MTA or an MDA that does not support DKIM
should avoid modifying messages in ways that prevent
verification by other MTAs, or MUAs to which the message may be
forwarded.
An inbound MTA or an MDA may incorporate an indication of the
verification results into the message, such as using an
Authentication-Results header.
[I-D.kucherawy-sender-auth-header]
Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the
sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary
+ SHOULD deploy abuse filtering measures on the inbound mail,
and
+ MAY remove all signatures that will be broken
In addition the intermediary MAY:
+ Verify the message signature prior to modification.
+ Incorporate an indication of the verification results into
the message, such as using an Authentication-Results header.
[I-D.kucherawy-sender-auth-header]
+ Sign the modified message including the verification results
(e.g., the Authentication-Results header).
2.3. Filtering
Developers of filtering schemes designed to accept DKIM
authentication results as input should be aware that their
implementations will be subject to counter-attack by email abusers.
The efficacy of a filtering scheme cannot therefore be determined by
reference to static test vectors alone; resistance to counter attack
must also be considered.
Naive learning algorithms that only consider the presence or absence
of a verified DKIM signature, without considering more information
about the message, are vulnerable to an attack in which a spammer or
other malefactor signs all their mail, thus creating a large negative
value for presence of a DKIM signature in the hope of discouraging
widespread use.
If heuristic algorithms are employed, they should be trained on
feature sets that sufficiently reveal the internal structure of the
DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not.
Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of a DKIM signature SHOULD be
ignored.
2.4. DNS Server
At a minimum, a DNS server that handles queries for DKIM key records
must allow the server administrators to add free-form TXT records.
It would, of course, be better for provide them with a structured
form, to support the DKIM-specific fields.
2.5. Deployment
This section describes the basic steps for introducing DKIM into an
organization's email service operation. The considerations are
divided between the generating DKIM signatures (Signing) and the
processing of messages that contain a DKIM signature (Verifying).
2.5.1. Key Management
Selectors Selectors are assigned according to the administrative
needs of the signing domain, such as for rolling over to a new key
or for delegating of the right to authenticate a portion of the
namespace to a trusted third party.
Examples include: jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.com
NOTE: It is intended that assessments of DKIM identities be
based on the domain name, and not include the selector.
This permits the selector to be used only for key
administration, rather than having an effect on reputation
assessment.
2.5.2. Signing
Creating messages that have DKIM signatures requires a modification
to only two portions of the email service:
o Addition of relevant DNS information.
o Addition of the signature by a trusted module within the
organization's email handling service.
The signing module uses the appropriate private key to create a
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.
2.5.2.1. DNS Records
A receiver attempting to verify a DKIM signature must obtain the
public key that is associated with the signature for that message.
The DKIM-Signature header in the message will specify the basic
domain name doing the signing and the selector to be used for the
specific public key. Hence, the relevant
<selector>._domainkey.<domain-name> DNS record needs to contain a
DKIM-related resource record (RR) that provides the public key
information.
The administrator of the zone containing the relevant domain name
adds this information. Initial DKIM DNS information is contained
within TXT RRs. DNS administrative software varies considerably in
its abilities to add new types of DNS records.
2.5.2.2. Signing Module
The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain (ADMD);
common choices are expected to be department-level posting and
delivering agents, as well as boundary MTAs to the open Internet.
(Note that it is entirely acceptable for MUAs to perform signing and
verification.) Hence the choice among the modules depends upon
software development and administrative overhead tradeoffs. One
perspective that helps resolve this choice is the difference between
the flexibility of use by systems at (or close to) the MUA, versus
the centralized control that is more easily obtained by implementing
the mechanism "deeper" into the organization's email infrastructure,
such as at its boundary MTA.
2.5.2.3. Signing Policies and Practices
Every organization (ADMD) will have its own policies and practices
for deciding when to sign messages and with what domain name and key
(selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing
practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software.
2.5.3. Verifying
2.5.3.1. Verifier
Verifiers SHOULD treat the result of the verification step as an
input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are
known.
In particular, verifiers SHOULD NOT automatically assume that an
email message that does not contain a signature, or that contains a
signature that does not verify, is forged. Verifiers should treat a
signature that fails to verify the same as if no signature were
present.
Verification is performed within an ADMD that wishes to make
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
verification and assessment -- such as filtering or presentation to
the recipient user -- depend on trade-offs for flexibility, control,
and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: the assessment
module MUST have a strong basis for believing that the verification
information is correct.
2.5.3.2. DNS Client
The primary means of publishing DKIM key information, initially, is
initially through DNS TXT records. Some DNS client software might
have problems obtaining these records; as DNS client software
improves this will not be a concern.
2.5.3.3. Boundary Enforcement
In order for an assessment module to trust the information it
receives about verification (e.g., Authentication-Results headers),
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
modules in the receiving and sending Boundary MTA(s) that strip any
existing verification information.
2.5.4. 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 relayed 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), 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.
2.5.5. Transition strategy
Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that signers and verifiers can phase in
support for the new algorithm independently, and (if necessary) phase
out support for the old algorithm independently.
[Note: this section assumes that a security policy mechanism exists.
It is subject to change.]
DKIM achieves these requirements through two features: First a signed
message may contain multiple signatures created by the same signer.
Secondly the security policy layer allows the signing algorithms in
use to be advertised, thus preventing a downgrade attack.
2.5.5.1. Signer transition strategy
Let the old signing algorithm be A, the new signing algorithm be B.
The sequence of events by which a Signer may introduce the new
signing algorithm B, without disruption of service to legacy
verifiers, is as follows:
1. Signer signs with algorithm A
A. Signer advertises that it signs with algorithm A
2. Signer signs messages twice, with both algorithm A and algorithm
B
A. The signer tests new signing configuration
B. Signer advertises that it signs with algorithm A and
algorithm B
3. Signer determines that support for Algorithm A is no longer
necessary
4. Signer determines that support for algorithm A is to be withdrawn
A. Signer removes advertisement for Algorithm A
B. Signer waits for cached copies of earlier signature policy to
expire
C. Signer stops signing with Algorithm A
2.5.5.2. Verifier transition strategy
The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm A to be
withdrawn. The decisions of the verifier must make are therefore:
o The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity
at a given key strength.
* A verifier MAY evaluate signature records in any order it
chooses, including using the signature algorithm to choose the
order.
o The verifier MAY make a determination that Algorithm A does not
offer a useful level of security, or that the cost of verifying
the signature is less than the value of doing so.
* In this case the verifier would ignore signatures created using
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
algorithms at any time.
* The verifier MAY add support for algorithm B at any time.
2.5.6. Migrating from DomainKeys
2.5.6.1. Signing
DNS Records: DKIM is upwardly compatible with existing
DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module
does not automatically require additional DNS administration!
However DKIM has enhanced the DomainKeys DNS key record format
by adding several additional optional parameters.
Boundary MTA: The principle use of DomainKeys is at Boundary
MTAs. Because no operational transition is ever instantaneous,
it is not adviseable for existing DomainKeys signers to switch
to DKIM without continuing to perform DomainKeys signing. A
signer should add a DKIM signature to a message that also has a
DomainKeys signature, until such time as DomainKeys receive-
side support is sufficiently reduced. With respect to signing
policies, a reasonable, initial approach is to use DKIM
signatures in the same way as DomainKeys signatures are already
being used.
2.5.6.2. Verifying
DNS Client: DNS queries for the DKIM key record, use the same
Domain Name naming conventions as were used for DomainKeys, and
the same basic record format. No changes to the DNS client
should be required.
Verifying module: See the section on Signing above.
2.6. On-going Operations
This section describes the basic steps for operation of email systems
that use DKIM, after the capability has initially been deployed. The
primary considerations are:
o the upkeep of the selector files, and
o the security of the private keys.
2.6.1. DNS Signature Record Installation Considerations
Even with use of the DNS, one challenge is that DNS record management
is usually operated by an administrative staff that is different from
those who operate an organization's email service. In order to
ensure that DKIM DNS records are accurate, this imposes a requirement
for careful coordination between the two operations groups.
The key point to remember is that the DNS DKIM selectors WILL and
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
o associations with clusters of servers
o the use of third party signers
o security considerations
2.6.1.1. Time Basis and Security Considerations
The reason for changing the selector periodically is usually related
to the security exposure of a system. When the potential exposure of
the private keys associated with the DKIM selector have reached
sufficient levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in deciding when
the exposure has reached sufficient levels to warrant changing the
selector.)
For example,
o Selectors should be changed more frequently on systems that are
widely exposed, than on systems that are less widely exposed. For
example, a gateway system that has numerous externally-accessible
services running on it, is more widely exposed than one that ONLY
runs a mail server.
o Selectors should be changed more frequently on operating systems
that are under wide attack.
o While the use of DKIM information is transient, keys with
sufficient exposure do become stale and should be changed.
o Whenever you make a substantial system change, such as bringing up
a new server, or making a major operating system change, you
should consider changing the selector.
o Whenever there is either suspicion or evidence of the compromise
of the system or the private keys, you should change the selector.
2.6.1.2. Deploying New Selectors
A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. 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:
1. Generate the new public / private key pair and create a new
selector record with the public key in it.
2. Add the new selector record to your DNS.
3. Verify that the new selector record can be used to verify
signatures.
4. Turn on signing with the new private key.
5. Remove the old private key from your servers.
6. After a period of time, remove the old selector from your DNS.
The time an unused selector should be kept in the DNS system is
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.
2.6.1.3. Subdomain Considerations
A Domain Name is the basis for making differential quality
assessments about a DKIM-signed message. It is reasonable for a
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.6.1.4. Third party Signature Delegations
Allowing third parties to sign email from your domain opens your
system security to include the security of the third party's systems.
At a minimum, you should not allow the third parties to use the same
selector and private key as your main mail system. It is recommended
that each third party be given their own private key and selector.
This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed.
2.6.2. Private Key Management
The permissions of private key files must be carefully managed. If
key management hardware support is available, it should be used.
Auditing software should be used to periodically verify that the
permissions on the private key files remain secure.
2.6.3. Mailing list manager developers
A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that flow through the list.
The desired goal is that messages flowing through the mailing list
will be verifiable by the recipient as being from the list, or
failing that, as being from the individual list members.
In most cases, the list and/or its mail host SHOULD add its own DKIM The MSA The MSA signs the message, using private information from
signature to list mail. This could be done in the list management the Key Store.
software, in an outgoing MSA or MTA, or both. List management
software often makes modifications to messages that will break
incoming signatures, such as adding subject tags, adding message
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 The MDA The MDA verifies the signature or determines whether a
are simple enough that signatures on incoming messages will still be signature was required. Verifying the signature uses public
verifiable after being remailed by the list. It is still preferable information from the Key Store. If the signature passes,
that the list sign its mail so that recipients can distinguish reputation information is used to asses the signer and that
between mail sent through the list and mail sent directly to a list information is passed to the message filtering system. If the
member. In the absence of a list signature, a recipient may still be signature fails or there is no signature, information about the
able to recognize and use the original signatures of the list sender's practices is retrieved remotely and/or locally, and that
members. information is passed to the message filtering system.
2.7. Example Uses Note: Figure 2 does not show the affects on the flow of multiple
signatures or third-party signatures.
A DKIM signature tells the signature verifier that the owner of a 7.1. Administration and Maintenance
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.
2.7.1. Protection of Internal Mail A number of tables and services are used to provide external
information. Each of these introduces administration and maintenance
requirements.
One identity is particularly amenable to easy and accurate Key Store DKIM uses public/private (asymmetric) key technology. The
assessment: The organization's own identity. Members of an signer users a private key and the validator uses the
organization tend to trust messages that purport to be from within corresponding public key. The current DKIM signing specification
that organization. However Internet Mail does not provide a provides for querying the Domain Names Service (DNS), to permit a
straightforward means of determining whether such mail is, in fact, validator to obtain the public key. The signing organization
from within the organization. DKIM can be used to remedy this therefore must have a means of adding a key to the DNS, for every
exposure. If the organization signs all of its mail, then its selector/domain-name combination. Further, the signing
boundary MTAs can look for mail purporting to be from the organization needs policies for distributing and revising keys.
organization but does not contain a verifiable signature. Such mail
can be presumed to be spurious.
2.7.2. Recipient-based Assessments Sender Practices If a message contains a valid signature, then the
verifier can evaluate the associated domain name's reputation. If
a message does not contain a valid signature, that fact could be
useful, if the verifier can discover information about the DKIM-
related practices of one of the agents purportedly involved with
the message, such as the domain listed in the author's FROM header
field. Such information might come from tables developed through
private agreement or from standards-based mechanisms. As they are
defined, each domain name owner will need to consider what
information to publish through the mechanism and then will need to
create and maintain it.
Recipients of large volumes of email can internally generate Reputation/Accreditation "Reputation/Accreditation" provides
reputation data for email senders. Recipients of smaller volumes of quality-assessment information that is associated with a domain
messages are likely to need to acquire reputation data from a third name, and comes in many forms and from many sources. DKIM does
party. In either case the use of reputation data is intrinsically not define these services. It's relevance to them is to provide a
limited to email senders that have established a prior history of validated domain name, upon which assessments can be made.
sending messages.
In fact, an email receiving service may be in a position to establish 7.2. Signing
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.
2.7.2.1. Third-party Assessments Signing can be performed by a component of the ADMD that creates the
message, and/or within any ADMD, along the relay path. The signer
uses the appropriate private key.
For scaling efficiency, it is appealing to have Trusted Third Party 7.3. Verifying
assessment 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.
2.7.3. DKIM Support in the Client Verification can be performed by any functional component along the
relay and delivery path. Verifiers retrieve the public key based
upon the parameters stored in the message.
The DKIM specification is expected to be used primarily between 7.4. Unverified or Unsigned Mail
Boundary MTAs, or other infrastructure components of the originating
and receiving ADMDs. However there is nothing in DKIM that is
specific to those venues. In particular, it should be possible to
support signing and verifying in MUAs.
However, it is common for components of an ADMD's email Note that a failed signature causes the message to be treated in the
infrastructure to do violence to a message, such as to render a DKIM same manner as one that is unsigned. Messages lacking a valid
signature invalid. Hence, users of MUAs that support DKIM signing originator signature (a signature associated with the originator of
and/or verifying need a basis for knowing that their associated email the message as opposed to a signature associated with an
infrastructure will not break a signature. intermediary) prompt a query for any published "sender practices"
information, as an aid in determining whether the sender information
has been used without authorization.
DKIM requires that all verifiers treat messages with signatures that 7.5. Evaluating
do not verify as if they are unsigned. If verification in the client
is to be acceptable to users, it is also essential that successful
verification of a signature not result in a less than satisfactory
user experience compared to leaving the message unsigned.
2.7.4. Per user signatures The Figure shows the verified identity as being used to assess an
associated reputation, but it could be applied for other tasks, such
as management tracking of mail. A popular use of reputation
information is as input to a filtering engine that decides whether to
deliver -- and possibly whether to specially mark -- a message.
Filtering engines have become complex and sophisticated. Their
details are outside of DKIM's scope, other than the expectation that
DKIM-related information is added to the varied soup of rules used by
the engines. The rules can cover signed messages and can deal with
unsigned messages from a domain, if the domain has published
information about is practices
Although DKIM's use of domain names is optimized for a scope of 8. Security Considerations
organization-level signing, it is possible to administer sub-domains
and/or selectors in a way that supports per-user signing.
NOTE: As stated earlier, it is important to distinguish between the TBD
use of selectors for differential administration of keys, versus
the use of sub-domains for differential reputations.
As a constraint on an authorized DKIM signing agent, their associated 9. IANA Considerations
key record can specify restrictions on the email addresses permitted
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 TBD
of public keys is likely to require infrastructure enhancements,
to support that management. For example, a system in which the
end user is required to generate a public key pair and transmit it
to the DNS administrator out of band is not likely to meet
acceptance criteria for either usability or security.
3. Acknowledgements 10. Acknowledgements
TBD TBD
4. Informative References 11. Informative References
[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 for Indicating Sender Kucherawy, M., "Message Header Field for Indicating
Authentication Status", Message Authentication Status",
draft-kucherawy-sender-auth-header-04 (work in progress), draft-kucherawy-sender-auth-header-09 (work in progress),
February 2007. November 2007.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [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.
 End of changes. 97 change blocks. 
1002 lines changed or deleted 516 lines changed or added

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