draft-ietf-dkim-overview-06.txt   draft-ietf-dkim-overview-07.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: May 14, 2008 Brandenburg InternetWorking Expires: May 21, 2008 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
November 11, 2007 November 18, 2007
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-06 draft-ietf-dkim-overview-07
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 May 14, 2008. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
DomainKeys Identified Mail (DKIM) allows an organization to take DomainKeys Identified Mail (DKIM) allows an organization to take
responsibility for a message, in a way that can be validated by a responsibility for a message, in a way that can be validated by a
recipient. The organization can be the author's, the originating recipient. The organization can be the author's, the originating
sending site, an intermediary, or one of their agent's. DKIM defines sending site, an intermediary, or one of their agent's. DKIM defines
a domain-level digital signature authentication framework for email, a domain-level digital signature authentication framework for email,
using public-key cryptography and key server technology. This using public-key cryptography and key server technology. This
permits verifying the signer of a message, as well as the integrity permits verifying the signer of a message, as well as the integrity
of its contents. The ultimate goal of this framework is to permit a of its contents. DKIM accomplishes this by defining a domain-level
signing domain to assert responsibility for a message, thus proving authentication framework for email using public-key cryptography and
and protecting the identity associated with the message and the key server technology [RFC4871]. This permits verifying a message
integrity of the messages itself, while retaining the functionality source, an intermediary, or one of their agents, as well as the
of Internet email as it is known today. Such protection of email integrity of its contents. DKIM will also provide a mechanism that
identity can assist in the global control of "spam" and "phishing". permits potential email signers to publish information about their
This document provides an overview of the DKIM service and describes email signing practices; this will permit email receivers to make
how it can fit into a messaging service. It also describes how DKIM additional assessments of unsigned messages. Such protection of
relates to other IETF message signature technologies. email identity can assist in the global control of "spam" and
"phishing". This document provides an overview of the DKIM service
and describes how it can fit into a messaging service. It also
describes how DKIM relates to other IETF message signature
technologies. It is intended for those who are adopting, developing,
or deploying DKIM.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5 1.2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6
2. Internet Mail Background . . . . . . . . . . . . . . . . . . . 5 2. Internet Mail Background . . . . . . . . . . . . . . . . . . . 6
2.1. Administrative Management Domain (ADMD) . . . . . . . . . 6 2.1. Administrative Management Domain (ADMD) . . . . . . . . . 6
2.2. DKIM Placement within an ADMD . . . . . . . . . . . . . . 8 2.2. DKIM Placement within an ADMD . . . . . . . . . . . . . . 8
3. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8 3. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 9
4. The Role of Trust . . . . . . . . . . . . . . . . . . . . . . 10 4. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10
5.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10 4.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11
5.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11 5. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13
6. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. The Basic Signing Service . . . . . . . . . . . . . . . . 13
6.1. The Basic Signing Service . . . . . . . . . . . . . . . . 13 5.2. Characteristics of a DKIM signature . . . . . . . . . . . 13
6.2. Characteristics of a DKIM signature . . . . . . . . . . . 13 5.3. The Selector construct . . . . . . . . . . . . . . . . . . 14
6.3. The Selector construct . . . . . . . . . . . . . . . . . . 13 5.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14 6. Service Architecture . . . . . . . . . . . . . . . . . . . . . 14
7. Service Architecture . . . . . . . . . . . . . . . . . . . . . 14 6.1. Administration and Maintenance . . . . . . . . . . . . . . 16
7.1. Administration and Maintenance . . . . . . . . . . . . . . 16 6.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 17 6.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 17
7.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 17 6.5. Evaluating . . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. Evaluating . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Informative References . . . . . . . . . . . . . . . . . . . . 18
11. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) allows an organization to take DomainKeys Identified Mail (DKIM) allows an organization to take
responsibility for a message, in a way that can be validated by a responsibility for a message, in a way that can be validated by a
recipient. The organization can be the author's, the originating recipient. The organization can be the author's, the originating
sending site, an intermediary, or one of their agent's. DKIM defines sending site, an intermediary, or one of their agent's. DKIM defines
a domain-level digital signature authentication framework for email, a domain-level digital signature authentication framework for email,
using public-key cryptography and key server technology. This using public-key cryptography and key server technology. This
permits verifying the signer of a message, as well as the integrity permits verifying the signer of a message, as well as the integrity
of its contents. DKIM accomplishes this by defining a domain-level of its contents. DKIM accomplishes this by defining a domain-level
authentication framework for email using public-key cryptography and authentication framework for email using public-key cryptography and
key server technology [RFC4871]. This permits verifying a message key server technology [RFC4871]. This permits verifying a message
source, an intermediary, or one of their agents, as well as the source, an intermediary, or one of their agents, as well as the
integrity of its contents. DKIM will also provide a mechanism that integrity of its contents. DKIM will also provide a mechanism that
permits potential email signers to publish information about their permits potential email signers to publish information about their
email signing practices; this will permit email receivers to make email signing practices; this will permit email receivers to make
additional assessments of unsigned messages. additional assessments of unsigned messages. Such protection of
email identity can assist in the global control of "spam" and
The ultimate goal of this framework is to permit a domain to assert "phishing".
responsibility for a message, thus proving and protecting the
identity associated with the message and the integrity of the
messages itself, while retaining the functionality of Internet email
as it is known today. Such protection of email identity, can assist
in the global control of "spam" and "phishing".
This document provides a description of DKIM's architecture and This document provides a description of DKIM's architecture and
functionality. It is intended for those who are adopting, functionality. It is intended for those who are adopting,
developing, or deploying DKIM. It also will be helpful for those who developing, or deploying DKIM. It also will be helpful for those who
are considering extending DKIM, either into other areas of use or to are considering extending DKIM, either into other areas of use or to
support additional features. This Overview does not provide support additional features. This Overview does not provide
information on threats to DKIM or email, or details on the protocol information on threats to DKIM or email, or details on the 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.
skipping to change at page 3, line 51 skipping to change at page 4, line 46
world's problems with spam, phishing, virii, worms, joe jobs, etc. world's problems with spam, phishing, virii, worms, joe jobs, etc.
DKIM provides one basic tool, in what needs to be a large arsenal, DKIM provides one basic tool, in what needs to be a large arsenal,
for improving basic trust in the Internet mail service. However by for improving basic trust in the Internet mail service. However by
itself, DKIM is not sufficient to that task and this Overview does itself, DKIM is not sufficient to that task and this Overview does
not pursue the issues of integrating DKIM into these larger efforts, not pursue the issues of integrating DKIM into these larger efforts,
beyond a simple reference within a system diagram. Rather, it is a beyond a simple reference within a system diagram. Rather, it is a
basic introduction to the technology and its use. basic introduction to the technology and its use.
1.1. Prior Work 1.1. Prior Work
Historical email assessment based on identity has been based on the Historical email assessment based on identity has used the IP Address
IP Address of a system that sent the message. The Address is of a system that sent the message. The Address is obtained via
obtained via underlying Internet information mechanisms and is underlying Internet information mechanisms and is therefore trusted
therefore trusted to be accurate. Besides having some known security to be accurate. Besides having some known security weaknesses, the
weaknesses, the use of Addresses present a number of functional and use of Addresses present a number of functional and operational
operational problems. Consequently there is an industry desire to problems. Consequently there is an industry desire to use a more
use a more stable value that has better correspondence to stable value that has better correspondence to organizational
organizational boundaries. Domain Names are viewed as satisfying boundaries. Domain Names are viewed as often 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 o PEM eventually transformed into MIME Object Security Services
(MOSS) in 1995. [RFC1848] Today, these two are only of historical (MOSS) in 1995. [RFC1848] Today, these two are only of historical
interest. 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 has continued. While both have
achieved a significant user base, neither have achieved ubiquity in achieved a significant user base, neither have achieved ubiquity in
deployment or use, and their goals differ from those of DKIM. deployment or use, and their goals differ from those of DKIM.
To the extent that other message-signing services might have been To the extent that other message-signing services might have been
adapted to do the job that DKIM is designed to perform, it was felt adapted to do the job that DKIM is designed to perform, it was felt
that re-purposing any of those would be more problematic than that re-purposing any of those would be more problematic than
creating a separate service. That said, DKIM uses security algorithm creating a separate service. That said, DKIM uses security algorithm
components that have a long history, including use within some of components that have a long history, including use within some of
those other messaging security services. those other messaging security services.
DKIM has a distinctive approach for distributing and vouching for DKIM has a distinctive approach for distributing and vouching for
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 provided by adding information records to the
records to the existing Domain Name System (DNS) [RFC1034], rather existing Domain Name System (DNS) [RFC1034], rather than requiring
than requiring deployment of a new query infrastructure. This deployment of a new query infrastructure. This approach has
approach has significant operational advantages. First, it avoids significant operational advantages. First, it avoids the
the considerable barrier of creating a new infrastructure; hence it considerable barrier of creating a new global infrastructure; hence
leverages a global base of administrative experience and highly it 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.2. Discussion Venue 1.2. Discussion Venue
NOTE TO RFC EDITOR: This "Discussion Venue" section is to be NOTE TO RFC EDITOR: This "Discussion Venue" section is to be
removed prior to publication. removed prior to publication.
skipping to change at page 5, line 35 skipping to change at page 6, line 29
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,
the author, and delivering it to one or more other users, the the author, and delivering it to one or more other users, the
recipients. This creates a virtual MUA-to-MUA exchange environment. recipients. This creates a virtual MUA-to-MUA exchange environment.
The first component of the MHS is called the Mail Submission Agent The first component of the MHS is called the Mail Submission Agent
(MSA) and the last is called the Mail Delivery Agent (MDA). (MSA) and the last is called the Mail Delivery Agent (MDA).
An email Mediator is both an inbound MDA and outbound MSA. It takes An email Mediator is both an inbound MDA and outbound MSA. It takes
delivery of a message and reposts it for further distribution, delivery of a message and re-posts it for further distribution,
retaining the original From header field. A mailing list is a common retaining the original From header field. A mailing list is a common
example of a Mediator example of a Mediator
The modern Internet Mail service is marked by many independent The modern Internet Mail service is marked by many independent
operators, many different components for providing users with service operators, many different components for providing users with service
and many other components for performing message transfer. and many other components for performing message transfer.
Consequently, it is necessary to distinguish administrative Consequently, it is necessary to distinguish administrative
boundaries that surround sets of functional components, which are boundaries that surround sets of functional components, which are
subject to coherent operational policies. subject to coherent operational policies.
As expanded on below, every MSA is a candidate for signing using As elaborated on below, every MSA is a candidate for signing using
DKIM, and every MDA is a candidate for doing DKIM verification. DKIM, and every MDA is a candidate for doing DKIM verification.
2.1. Administrative Management Domain (ADMD) 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
skipping to change at page 7, line 27 skipping to change at page 8, line 4
| Edge---+---+ | | Edge---+---+ |
| | | +----------+ | | | | +----------+ |
+--------+ | | ADMD#2 | | +--------+ | | 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 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 signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM
verification. 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 a single ADMD are subject to the policies of that domain.
Although any pair of ADMDs can arrange for whatever policies they
wish, Internet Mail is designed to permit inter-operation without
prior arrangement.
Common ADMD examples are: Common ADMD examples are:
Enterprise Service Providers: Enterprise Service Providers:
Operators of an organization's internal data and/or mail Operators of an organization's internal data and/or mail
services. services.
Internet Service Providers: Internet Service Providers:
skipping to change at page 8, line 15 skipping to change at page 8, line 41
Mail Service Providers: Mail Service Providers:
Operators of email services, such as for end-users, or Operators of email services, such as for end-users, or
mailing lists. mailing lists.
2.2. DKIM Placement within an ADMD 2.2. DKIM Placement within an ADMD
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 infrastructures of the originating organization's will be within the infrastructures of the originating organization's
outbound service and and the receiving organization's inbound outbound service and the receiving organization's inbound service,
service, such as a department or a boundary MTA. DKIM can be such as a department or a boundary MTA. DKIM can be implemented in
implemented in an author's or recipient MUA, but this is expected to an author's or recipient MUA, but this is expected to be less
be less typical, since it has higher administration and support typical, since it has higher administration and support costs.
costs.
A Mediator, such as a mailing list, often can re-post a message A Mediator, such as a mailing list, often can re-post a message
without breaking the DKIM signature. Furthermore it can add its own without breaking the DKIM signature. Furthermore it can add its own
signature. This can be added by the Mediator software itself, or by signature. This can be added by the Mediator software itself, or by
any outbound component in the Mediator's ADMD. any outbound component in the Mediator's ADMD.
3. The DKIM Value Proposition 3. The DKIM Value Proposition
The nature and origins of a message are often falsely stated. As a The nature and origins of a message are often falsely stated. As a
foundation for distinguishing legitimate mail, DKIM provides a means foundation for distinguishing legitimate mail, DKIM provides a means
skipping to change at page 9, line 8 skipping to change at page 9, line 34
2. Determine whether the identity is known or unknown 2. Determine whether the identity is known or unknown
3. Determine whether a known identity is trusted 3. Determine whether a known identity is trusted
The role of DKIM is in the first two of these; DKIM is an enabler for The role of DKIM is in the first two of these; DKIM is an enabler for
the third. the third.
An attack is made against an organization or against customers of an An attack is made against an organization or against customers of an
organization. The name of the organization is linked to particular organization. The name of the organization is linked to particular
Internet domain names. One point of leverage used by attackers is Internet domain names. One point of leverage used by attackers is
either to spoof a legitimate domain name, or to use a "cousin" name either to use a legitimate domain name, without authorization or to
that is similar to one that is legitimate, but is not controlled by use a "cousin" name that is similar to one that is legitimate, but is
the target organization. A DKIM-based accreditation service can not controlled by the target organization. A DKIM-based assessment
enforce a basic separation between domains used by such known service can enforce a basic separation between domains used by such
organizations and domains used by others. known organizations and domains used by others.
DKIM signatures can be created by a direct handler of a message, DKIM signatures can be created by a direct handler of a message,
either as its originator or as an intermediary. It can also be either as its originator or as an intermediary. It can also be
created by an independent service, providing assistance to a handler created by an independent service, providing assistance to a handler
of the message. Whoever does the signing chooses the domain name to of the message. Whoever does the signing chooses the domain name to
be used as the basis for later assessments. Hence, reputation be used as the basis for later assessments. Hence, reputation
associated with that domain name is the basis for evaluating whether associated with that domain name is the basis for evaluating whether
to trust the message for delivery. The owner of the domain name to trust the message for delivery. The owner of the domain name
being used for a DKIM signature is declaring that they are being used for a DKIM signature is declaring that they are
accountable for the message. accountable for the message.
DKIM is intended to be a value-added feature for email. Mail that is DKIM is a value-added feature for email. Mail that is not signed by
not signed by DKIM is handled in the same way as it was, before DKIM DKIM is handled in the same way as it was, before DKIM was defined;
was defined; it continues to be evaluated by established analysis and it continues to be evaluated by established analysis and filtering
filtering techniques. Over time, widespread DKIM adoption could techniques. Over time, widespread DKIM adoption could permit more
permit more strict handling of messages that are not signed. However strict handling of messages that are not signed. However early
early benefits do not require this and probably do not warrant this. benefits do not require this and probably do not warrant this.
It is important to be clear about the narrow scope of DKIM's It is important to be clear about the narrow scope of DKIM's
capabilities. It is an enabling technology, intended for use in the capabilities. It is an enabling technology, intended for use in the
larger context of determining message legitimacy. This larger larger context of determining message legitimacy. This larger
context is complex, so that it is easy to assume that a component context is complex, so it is easy to assume that a component like
like DKIM, which actually provides only a limited service, instead DKIM, which actually provides only a limited service, instead
satisfies the broader set of requirements. A DKIM signature: satisfies the broader set of requirements. A DKIM signature:
o Does not offer any assertions about the behaviors of the identity o Does not offer any assertions about the behaviors of the identity
doing the signing. doing the signing.
o Does not prescribe any specific actions for receivers to take upon o Does not prescribe any specific actions for receivers to take upon
successful signature verification. successful signature verification.
o Does not provide protection after signature verification. o Does not provide protection after signature verification.
o Does not protect against re-sending (replay of) a message that o Does not protect against re-sending (replay of) a message that
already has a verified signature; therefore a transit intermediary already has a verified signature; therefore a transit intermediary
or a recipient can re-post the message in such a way that the or a recipient can re-post the message in such a way that the
signature would remain verifiable, although the new recipient(s) signature would remain verifiable, although the new recipient(s)
would not have been specified by the author. would not have been specified by the author.
4. The Role of Trust 4. DKIM Goals
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 DKIM adds an end-to-end authentication mechanism to the existing
email transfer infrastructure. This motivates functional goals about email transfer infrastructure. This motivates functional goals about
authentication and operational goals about integration with the the authentication itself and operational goals about its integration
existing email service. with the rest of the Internet email service.
5.1. Functional Goals 4.1. Functional Goals
5.1.1. Use Domain-level granularity for assurance. 4.1.1. Use Domain-level granularity for assurance.
OpenPGP and S/MIME apply the end-to-end principle in terms of OpenPGP and S/MIME provide end-to-end validation in terms of
individual originators and recipients, notably using full email individual originators and recipients, notably using full email
addresses. DKIM seeks accountability at the more coarse granularity addresses, whereas DKIM seeks accountability at the more coarse
of an organization or, perhaps, a department. An existing Internet granularity of an organization or, perhaps, a department. An
service construct that enables this granularity is the Domain Name existing Internet service construct that enables this granularity is
[RFC1034], to which the signing key record is bound. Further DKIM the Domain Name [RFC1034], to which the signing key record is bound.
signing and/or validating can be implemented anywhere along the Further DKIM signing and/or validating can be implemented anywhere
transit path, rather than only in the end systems or only in the along the transit path, rather than only in the end systems or only
boundary MTA. in the boundary MTA.
5.1.2. Allow delegation of signing to independent parties. 4.1.2. Allow delegation of signing to independent parties.
Different parties have different roles in the process of email Different parties have different roles in the process of email
exchange. Some are easily visible to end users and others are exchange. Some are easily visible to end users and others are
primarily visible to operators of the service. DKIM needs to support primarily visible to operators of the service. DKIM needs to support
signing by any of these different parties and needs to permit them to 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 sign with any domain name that they deem appropriate (and for which
they are authorized.) As an example an organization that creates they are authorized.) As an example an organization that creates
email content often delegates portions of its processing or email content often delegates portions of its processing or
transmission to an outsourced group. DKIM supports this mode of transmission to an outsourced group. DKIM supports this mode of
activity, in a manner that is not visible to end users. activity, in a manner that is not visible to end users.
5.1.3. Distinguish the core authentication mechanism from its 4.1.3. Distinguish the core authentication mechanism from its
derivative uses. derivative uses.
An authenticated identity can be subject to a variety of processing An authenticated identity can be subject to a variety of processing
policies, either ad hoc or standardized. The only semantics inherent policies, either ad hoc or standardized. The only semantics inherent
to a DKIM signature is that the signer is asserting (some) to a DKIM signature is that the signer is asserting (some)
responsibility for the message. All other mechanisms and meanings responsibility for the message. All other mechanisms and meanings
are independent of this core service. One such mechanism might are independent of this core service. One such mechanism might
assert a relationship between the signing identity and the author, as assert a relationship between the signing identity and the author, as
specified in the From header field's domain identity[RFC2822]. specified in the From header field's domain identity[RFC2822].
Another might specify how to treat an unsigned message with that From Another might specify how to treat an unsigned message with that From
field domain. field domain.
5.1.4. Retain ability to have anonymous email. 4.1.4. Retain ability to have anonymous email.
The ability to send a message that does not identify its author is 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 considered to be a valuable quality of the current email service that
needs to be retained. DKIM is compatible with this goal since it needs to be retained. DKIM is compatible with this goal since it
permits an email system operator to be authenticated, rather than the permits an email system operator to be authenticated, rather than the
content author. Knowing that a message definitely came from content author. Knowing that a message definitely came from
example.com does not threaten the anonymity of the user who authored example.com does not threaten the anonymity of the user who authored
it, if it is still possible to obtain effectively anonymous accounts it, if it is still possible to obtain effectively anonymous accounts
at example.com. at example.com.
5.2. Operational Goals 4.2. Operational Goals
5.2.1. Treat verification failure the same as no signature present. 4.2.1. Treat verification failure the same as no signature present.
OpenPGP and S/MIME were both designed for strong cryptographic OpenPGP and S/MIME were designed for strong cryptographic protection.
protection. This included treating verification failure as message This included treating verification failure as message failure. As a
failure. As a sub-goal to the requirement for transparency, a DKIM sub-goal to the requirement for transparency, a DKIM signature
signature verifier is to treat messages with signatures that fail as verifier is to treat messages with signatures that fail as if they
if they were unsigned. Hence the message will revert to normal were unsigned. Hence the message will revert to normal handling,
handling, through the receiver's existing filtering mechanisms. through the receiver's existing filtering mechanisms. Thus, DKIM
Thus, a sender cannot apply a broken signture and force a message to specifies that a sender is not to take a message that has a broken
be treated any differently than if the signature weren't there. signature and treat it any differently than if the signature weren't
there.
5.2.2. Make signatures transparent to non-supporting recipients. 4.2.2. Make signatures transparent to non-supporting recipients.
S/MIME and OpenPGP both modify the message body. Hence, their S/MIME and OpenPGP modify the message body. Hence, their presence is
presence is potentially visible to email recipients and their user potentially visible to email recipients, whose user software needs to
software needs to process the associated constructs. In order to process the associated constructs. In order to facilitate
facilitate incremental adoption, DKIM is designed to be transparent incremental adoption, DKIM is designed to be transparent to
to recipients that do not support it. A DKIM signature cannot "get recipients that do not support it. A DKIM signature does not "get in
in the way" for such recipients. the way" for such recipients.
5.2.3. Permit incremental adoption for incremental benefit. 4.2.3. Permit incremental adoption for incremental benefit.
DKIM can immediately provide benefits between any two organizations DKIM can immediately provide benefits between any two organizations
that exchange email and implement DKIM. In the usual manner of that exchange email and implement DKIM. In the usual manner of
"network effects", the benefits of DKIM increase dramatically as its "network effects", the benefits of DKIM increase dramatically as its
adoption increases. 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, they independent services to aid in the assessment of DKIM results, they
are not essential in order to obtain initial benefit. For example are not essential in order to obtain initial benefit. For example
DKIM allows (possibly large) pair-wise sets of email providers and DKIM allows (possibly large) pair-wise sets of email providers and
spam filtering companies to distinguish mail that is associated with spam filtering companies to distinguish mail that is associated with
a known organization, from mail that might deceptively purport to a known organization, from mail that might deceptively purport to
have the affiliation. This in turn allows the development of have the affiliation. This in turn allows the development of
"whitelist" schemes whereby authenticated mail from a known source "whitelist" schemes whereby authenticated mail from a known source
with good reputation is allowed to bypass some spam filters. with good reputation is allowed to bypass some anti-abuse filters.
In effect the email receiver is using their set of known In effect the email receiver is using their set of known
relationships to generate their own reputation data. This works relationships to generate their own reputation data. This works
particularly well for traffic between large sending providers and particularly well for traffic between large sending providers and
large receiving providers. However it also works well for any large receiving providers. However it also works well for any
operator, public or private, that has mail traffic dominated by operator, public or private, that has mail traffic dominated by
exchanges among a stable set of organizations. exchanges among a stable set of organizations.
5.2.4. Minimize the amount of required infrastructure 4.2.4. Minimize the amount of required infrastructure
A new service, or an enhancement to an existing service, requires A new service, or an enhancement to an existing service, requires
adoption by some number of systems, before it can be useful. The adoption by some number of systems, before it can be useful. The
greater the number of required adopters, the higher the adoption greater the number of required adopters, the higher the adoption
barrier. This becomes particularly serious when adoption is required barrier. This becomes particularly serious when adoption is required
by intermediary -- that is, infrastructure -- service providers. In by intermediary -- that is, infrastructure -- service providers. In
order to allow early adopters to gain early benefit, DKIM makes no order to allow early adopters to gain early benefit, DKIM makes no
changes to the core Internet Mail service and, instead, can provide a changes to the core Internet Mail service and, instead, can provide a
useful benefit for any signer/verifier pair of participants useful benefit for any signer/verifier pair of participants
exchanging mail. Similarly, DKIM's reliance on the Domain Name exchanging mail. Similarly, DKIM's reliance on the Domain Name
System greatly reduces the amount of new administrative System greatly reduces the amount of new administrative
infrastructure that is need, across the open Internet. infrastructure that is need, across the open Internet.
5.2.5. Permit wide range of deployment choices. 4.2.5. Permit wide range of deployment choices.
DKIM can be deployed at a variety of places within an organization's DKIM can be deployed at a variety of places within an organization's
email service. This permits the organization to choose how much or email service. This permits the organization to choose how much or
how little they want DKIM to be part of their service, rather than how little they want DKIM to be part of their service, rather than
part of a more localized operation. part of a more localized operation.
6. DKIM Function 5. 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 author to a set of recipients. email while it is in transit, from an author to a set of recipients.
It creates the ability to associate verifiable information with a It creates the ability to associate verifiable information with a
message, especially a responsible identity. When a message is not message, especially a responsible identity. When a message is not
signed, DKIM permits the identity of the sender to be used for signed, DKIM will permit the domain name of the author to be used for
obtaining information about their signing practices. obtaining information about their signing practices.
6.1. The Basic Signing Service 5.1. The Basic Signing Service
With the DKIM signature mechanism, a signer chooses a signing With the DKIM signature mechanism, a signer chooses a signing
identity based on their domain name, performs digital signing on the identity based on their domain name, performs digital signing on the
message, and records signature information in a DKIM header field. A message, and records signature information in a DKIM header field. A
verifier obtains the domain name and the "selector" from the DKIM verifier obtains the domain name and the "selector" from the DKIM
header field, queries for a public key associated with the name, and header field, queries for a public key associated with the name, and
verifies the signature. verifies the signature.
DKIM permits any domain name to be used 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 that all Internet standards, there is a core set of algorithms that all
implementations are required to support, in order to guarantee basic implementations are required to support, in order to guarantee basic
interoperability. This ensures an initial ability to interoperate. interoperability.
DKIM permits restricting the use of a signature key to particular DKIM permits restricting the use of a signature key to signing
types of services, such as only for email. This is helpful when messages for particular types of services, such as only for email.
delegating signing authority, such as to a particular department or This is helpful when delegating signing authority, such as to a
to a third-party outsourcing service. particular department or to a third-party outsourcing service.
With DKIM the signer explicitly lists the headers that are signed. With DKIM the signer explicitly lists the headers that are signed.
By choosing the minimal set of headers needed, the signature is By choosing the minimal set of headers needed, the signature is
likely to be considerably more robust against the handling the likely to be considerably more robust against the handling vagaries
vagaries of intermediary MTAs. of intermediary MTAs.
6.2. Characteristics of a DKIM signature 5.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.
6.3. The Selector construct 5.3. The Selector construct
A signature is associated with a domain name, as specified in the The key for a signature is associated with a domain name, as
"i=" (or "d=" if "i=" is not present) DKIM-Signature header field specified in the d= DKIM-Signature header field parameter. That
parameters. That domain name is the complete identity used for domain name is the complete identity used for making assessments
making assessments about the signer. However this name is not about the signer. However this name is not sufficient for making a
sufficient for making a DNS query to obtain the key needed to verify DNS query to obtain the key needed to verify the signature.
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", coded into separate DKIM-Signature header field "selector", coded into separate DKIM-Signature header field
parameters. parameters.
NOTE: The selector is not intended to be 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 strictly reserved for use in administering keys that are
skipping to change at page 14, line 30 skipping to change at page 14, line 37
one. one.
Signers often need to support multiple assessments about their Signers often need to support multiple assessments about 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, one method is for an organization assessments that are independent, one method is for an organization
to use 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".
6.4. Verification 5.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 verify the signature, to determine that the signing identity path can verify the signature, to determine that the signing identity
took responsibility for the message. Message recipients can verify took responsibility for the message. Message recipients can verify
the signature by querying the DNS for the signer's domain directly, the signature by querying the DNS for the signer's domain directly,
to retrieve the appropriate public key, and thereby confirm that the to retrieve the appropriate public key, and thereby confirm that the
message was attested to by a party in possession of the private key message was attested to by a party in possession of the private key
for the signing domain. Typically, verification will be done by an for the signing domain. Typically, verification will be done by an
agent in the ADMD of the message recipient. agent in the ADMD of the message recipient.
7. Service Architecture 6. 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
skipping to change at page 15, line 34 skipping to change at page 15, line 38
. | 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 | +--------+ | | Local |
+.......>| Assess | | | Sender | +.......>| Assess | | | Sender |
. | Signer | | | Practices | . | Signer | | | Practices |
. +---+----+ | +-----------+ . +---+----+ | +-----------+
. assessment| | . assessment| |
. +------+ +------+ . +------+ +------+
. | | . | |
+-+-----------+ V V +-+-----------+ V V
| Reputation/ | +-----------+ | Reputation/ | +-----------+
skipping to change at page 16, line 18 skipping to change at page 16, line 23
The MDA The MDA verifies the signature or determines whether a The MDA The MDA verifies the signature or determines whether a
signature was required. Verifying the signature uses public signature was required. Verifying the signature uses public
information from the Key Store. If the signature passes, information from the Key Store. If the signature passes,
reputation information is used to asses the signer and that reputation information is used to asses the signer and that
information is passed to the message filtering system. If the information is passed to the message filtering system. If the
signature fails or there is no signature, information about the signature fails or there is no signature, information about the
sender's practices is retrieved remotely and/or locally, and that sender's practices is retrieved remotely and/or locally, and that
information is passed to the message filtering system. information is passed to the message filtering system.
Note: Figure 2 does not show the affects on the flow of multiple Note: Figure 2 does not show the effects on the message-handling
signatures or third-party signatures. flow when multiple signatures or third-party signatures are
present.
7.1. Administration and Maintenance 6.1. Administration and Maintenance
A number of tables and services are used to provide external A number of tables and services are used to provide external
information. Each of these introduces administration and maintenance information. Each of these introduces administration and maintenance
requirements. requirements.
Key Store DKIM uses public/private (asymmetric) key technology. The Key Store DKIM uses public/private (asymmetric) key technology. The
signer users a private key and the validator uses the signer users a private key and the validator uses the
corresponding public key. The current DKIM signing specification corresponding public key. The current DKIM signing specification
provides for querying the Domain Names Service (DNS), to permit a provides for querying the Domain Names Service (DNS), to permit a
validator to obtain the public key. The signing organization validator to obtain the public key. The signing organization
skipping to change at page 17, line 6 skipping to change at page 17, line 12
defined, each domain name owner will need to consider what defined, each domain name owner will need to consider what
information to publish through the mechanism and then will need to information to publish through the mechanism and then will need to
create and maintain it. create and maintain it.
Reputation/Accreditation "Reputation/Accreditation" provides Reputation/Accreditation "Reputation/Accreditation" provides
quality-assessment information that is associated with a domain quality-assessment information that is associated with a domain
name, and comes in many forms and from many sources. DKIM does name, and comes in many forms and from many sources. DKIM does
not define these services. It's relevance to them is to provide a not define these services. It's relevance to them is to provide a
validated domain name, upon which assessments can be made. validated domain name, upon which assessments can be made.
7.2. Signing 6.2. Signing
Signing can be performed by a component of the ADMD that creates the 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 message, and/or within any ADMD along the relay path. The signer
uses the appropriate private key. uses the appropriate private key.
7.3. Verifying 6.3. Verifying
Verification can be performed by any functional component along the Verification can be performed by any functional component along the
relay and delivery path. Verifiers retrieve the public key based relay and delivery path. Verifiers retrieve the public key based
upon the parameters stored in the message. upon the parameters stored in the message.
7.4. Unverified or Unsigned Mail 6.4. Unverified or Unsigned Mail
Note that a failed signature causes the message to be treated in the Note that a failed signature causes the message to be treated in the
same manner as one that is unsigned. Messages lacking a valid same manner as one that is unsigned. Messages lacking a valid
originator signature (a signature associated with the originator of originator signature (a signature associated with the originator of
the message as opposed to a signature associated with an the message as opposed to a signature associated with an
intermediary) prompt a query for any published "sender practices" intermediary) prompt a query for any published "sender practices"
information, as an aid in determining whether the sender information information, as an aid in determining whether the sender information
has been used without authorization. has been used without authorization.
7.5. Evaluating 6.5. Evaluating
The Figure shows the verified identity as being used to assess an The Figure shows the verified identity as being used to assess an
associated reputation, but it could be applied for other tasks, such associated reputation, but it could be applied for other tasks, such
as management tracking of mail. A popular use of reputation as management tracking of mail. A popular use of reputation
information is as input to a filtering engine that decides whether to information is as input to a filtering engine that decides whether to
deliver -- and possibly whether to specially mark -- a message. deliver -- and possibly whether to specially mark -- a message.
Filtering engines have become complex and sophisticated. Their Filtering engines have become complex and sophisticated. Their
details are outside of DKIM's scope, other than the expectation that 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 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 the engines. The rules can cover signed messages and can deal with
unsigned messages from a domain, if the domain has published unsigned messages from a domain, if the domain has published
information about is practices information about is practices
8. Security Considerations 7. Security Considerations
TBD TBD
9. IANA Considerations 8. IANA Considerations
TBD TBD
10. Acknowledgements 9. Acknowledgements
TBD TBD
11. Informative References 10. 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 Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", Message Authentication Status",
draft-kucherawy-sender-auth-header-09 (work in progress), draft-kucherawy-sender-auth-header-09 (work in progress),
 End of changes. 60 change blocks. 
173 lines changed or deleted 153 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/