draft-ietf-dkim-overview-09.txt | draft-ietf-dkim-overview-10-02dc.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: August 28, 2008 Brandenburg InternetWorking | Expires: January 12, 2009 Brandenburg InternetWorking | |||
P. Hallam-Baker | P. Hallam-Baker | |||
VeriSign Inc. | VeriSign Inc. | |||
February 25, 2008 | July 11, 2008 | |||
DomainKeys Identified Mail (DKIM) Service Overview | DomainKeys Identified Mail (DKIM) Service Overview | |||
draft-ietf-dkim-overview-09 | draft-ietf-dkim-overview-10-02dc | |||
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 August 28, 2008. | This Internet-Draft will expire on January 12, 2009. | |||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2008). | ||||
Abstract | Abstract | |||
This document provides an overview of the DomainKeys Identified Mail | This document provides an overview of the DomainKeys Identified Mail | |||
(DKIM) service and describes how it can fit into a messaging service. | (DKIM) service and describes how it can fit into a messaging service. | |||
It also describes how DKIM relates to other IETF message signature | It also describes how DKIM relates to other IETF message signature | |||
technologies. It is intended for those who are adopting, developing, | technologies. It is intended for those who are adopting, developing, | |||
or deploying DKIM. DKIM allows an organization to take | or deploying DKIM. DKIM allows an organization to take | |||
responsibility for transmitting a message, in a way that can be | responsibility for transmitting a message, in a way that can be | |||
validated by a recipient. The organization can be the author's, the | validated by a recipient. The organization can be the author's, the | |||
originating sending site, an intermediary, or one of their agents. | originating sending site, an intermediary, or one of their agents. A | |||
An organization may use one or more domain names to accomplish this. | message can contain multiple signatures, from the same or different | |||
DKIM defines a domain-level digital signature authentication | organizations involved with the message. DKIM defines a domain-level | |||
framework for email, using public-key cryptography and key server | digital signature authentication framework for email, using public- | |||
technology [RFC4871]. This permits verification of a message source, | key cryptography, using the domain name service as its key server | |||
an intermediary, or one of their agents, as well as the integrity of | technology [RFC4871]. This permits verification of a responsible | |||
its contents. DKIM will also provide a mechanism that permits | organization, as well as the integrity of the message contents. DKIM | |||
potential email signers to publish information about their email | will also provide a mechanism that permits potential email signers to | |||
signing practices; this will permit email receivers to make | publish information about their email signing practices; this will | |||
additional assessments about messages. Such protection of email | permit email receivers to make additional assessments about messages. | |||
identity can assist in the global control of "spam" and "phishing". | DKIM's authentication of email identity can assist in the global | |||
control of "spam" and "phishing.. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 6 | 1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 6 | |||
1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6 | 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6 | 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Identity Verification . . . . . . . . . . . . . . . . . . 7 | 2.1. Identity Verification . . . . . . . . . . . . . . . . . . 7 | |||
2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 7 | 2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 7 | |||
3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3. Establishing Message Validity . . . . . . . . . . . . . . 8 | |||
3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 8 | 3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 9 | 3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 9 | |||
4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 10 | |||
4.1. The Basic Signing Service . . . . . . . . . . . . . . . . 11 | 4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.2. Characteristics of a DKIM signature . . . . . . . . . . . 11 | 4.1. The Basic Signing Service . . . . . . . . . . . . . . . . 12 | |||
4.3. The Selector construct . . . . . . . . . . . . . . . . . . 11 | 4.2. Characteristics of a DKIM signature . . . . . . . . . . . 12 | |||
4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 12 | 4.3. The Selector construct . . . . . . . . . . . . . . . . . . 12 | |||
4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 13 | 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.1. Administration and Maintenance . . . . . . . . . . . . . . 15 | 5.1. Administration and Maintenance . . . . . . . . . . . . . . 15 | |||
5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 16 | 5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 16 | |||
5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5.6. DKIM Placement within an ADMD . . . . . . . . . . . . . . 17 | 5.6. DKIM Placement within an ADMD . . . . . . . . . . . . . . 17 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. Informative References . . . . . . . . . . . . . . . . . . . . 17 | 9. Informative References . . . . . . . . . . . . . . . . . . . . 18 | |||
Appendix A. Internet Mail Background . . . . . . . . . . . . . . 19 | Appendix A. Internet Mail Background . . . . . . . . . . . . . . 19 | |||
A.1. Administrative Management Domain (ADMD) . . . . . . . . . 19 | A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 | A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 20 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 23 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 24 | ||||
1. Introduction | 1. Introduction | |||
This document provides a description of the architecture and | This document provides a description of the architecture and | |||
functionality for DomainKeys Identified Mail (DKIM). It is intended | functionality for DomainKeys Identified Mail (DKIM). It is intended | |||
for those who are adopting, developing, or deploying DKIM. It will | for those who are adopting, developing, or deploying DKIM. It will | |||
also be helpful for those who are considering extending DKIM, either | also be helpful for those who are considering extending DKIM, either | |||
into other areas of use or to support additional features. This | into other areas of use or to support additional features. This | |||
overview does not provide information on threats to DKIM or email, or | overview does not provide information on threats to DKIM or email, or | |||
details on the protocol specifics, which can be found in [RFC4686] | details on the protocol specifics, which can be found in [RFC4686] | |||
and [RFC4871], respectively. The document assumes a background in | and [RFC4871], respectively. The document assumes a background in | |||
basic email and network security technology and services. | basic email and network security technology and services. | |||
DKIM allows an organization to take responsibility for a message, in | DKIM allows an organization to take responsibility for a message, in | |||
a way that can be validated by a recipient. The organization can be | a way that can be validated by a recipient. The organization can be | |||
the author's, the originating sending site, an intermediary, or one | handling the message directly, such as the author's, the originating | |||
of their agents. DKIM defines a domain-level digital signature | sending site or an intermediary. It also can also be created by an | |||
authentication framework for email through the use of public-key | independent service that is providing assistance to a handler. DKIM | |||
cryptography and key server technology. [RFC4871] It permits | defines a domain-level digital signature authentication framework for | |||
email through the use of public-key cryptography and using the domain | ||||
name service as its key server technology. [RFC4871] It permits | ||||
verification of the signer of a message, as well as the integrity of | verification of the signer of a message, as well as the integrity of | |||
its contents. DKIM will also provide a mechanism that permits | its contents. DKIM will also provide a mechanism that permits | |||
potential email signers to publish information about their email | potential email signers to publish information about their email | |||
signing practices; this will permit email receivers to make | signing practices; this will permit email receivers to make | |||
additional assessments of unsigned messages. Such protection of | additional assessments of unsigned messages. DKIM's authentication | |||
email identity can assist in the global control of "spam" and | of email identity can assist in the global control of "spam" and | |||
"phishing". | "phishing.. | |||
Neither this document nor DKIM attempts to provide solutions to the | Neither this document nor DKIM attempts to provide solutions to the | |||
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. DKIM's Scope | 1.1. DKIM's Scope | |||
DKIM signatures can be created by a direct handler of a message, | A person or organization has an "identity"; that is a constellation | |||
either as its author or as an intermediary. It can also be created | of characteristics that distinguish from any other identity. | |||
by an independent service that is providing assistance to a handler | Associated with this abstraction can be a label used as a reference, | |||
of the message. Whoever does the signing chooses the domain name to | or "identifier". (This is the distinction between a thing and the | |||
be used as the basis for later assessments. Hence, the reputation | name of the thing.) DKIM uses a domain name as an identifier, to | |||
associated with that domain name is an additional basis for | refer to the identity of a person or organization. Note that the | |||
evaluating whether to trust the message for delivery. The owner of | same identity can have multiple identifiers. | |||
the domain name being used for a DKIM signature is declaring that | ||||
they accept responsibility for the message and may thus be held | A DKIM signature can be created by a direct handler of a message, | |||
accountable for it. | such as the message's author or an intermediary. A signature also | |||
can be created by an independent service that is 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, | ||||
the reputation associated with that domain name might be an | ||||
additional 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 accept responsibility for the | ||||
message and can thus be held accountable for it. | ||||
DKIM is intended as a value-added feature for email. Mail that is | DKIM is intended as a value-added feature for email. Mail that is | |||
not signed by DKIM is handled in the same way as it was before DKIM | not signed by DKIM is handled in the same way as it was before DKIM | |||
was defined. The message will be evaluated by established analysis | was defined. The message will be evaluated by established analysis | |||
and filtering techniques. (A signing policy may provide additional | and filtering techniques. (A signing policy can provide additional | |||
information for that analysis and filtering.) Over time, widespread | information for that analysis and filtering.) Over time, widespread | |||
DKIM adoption could permit more strict handling of messages that are | DKIM adoption could permit more strict handling of messages that are | |||
not signed. However early benefits do not require this and probably | not signed. However early benefits do not require this and probably | |||
do not warrant this. | do not warrant this. | |||
DKIM's capabilities have a narrow scope. It is an enabling | DKIM has a narrow scope. It is an enabling technology, intended for | |||
technology, intended for use in the larger context of determining | use in the larger context of determining message legitimacy. This | |||
message legitimacy. This larger context is complex, so it is easy to | larger context is complex, so it is easy to assume that a component | |||
assume that a component like DKIM, which actually provides only a | like DKIM, which actually provides only a limited service, instead | |||
limited service, instead satisfies the broader set of requirements. | satisfies the broader set of requirements. | |||
By itself, a DKIM signature: | By itself, 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 signer. | |||
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 -- that is, post it as a | |||
signature would remain verifiable, although the new recipient(s) | new message -- in such a way that the signature would remain | |||
would not have been specified by the author. | verifiable, although the new recipient(s) might be different from | |||
those which were originally specified by the author. | ||||
1.2. Prior Work | 1.2. Prior Work | |||
Historically, email delivery assessment decisions have been based on | Historically, the IP Address of the system that directly sent the | |||
an identity that used the IP Address of the system that directly sent | message -- that is, the previous email "hop" -- has been treated as | |||
the message (that is, the previous email "hop"), [RFC4408] or on the | an identity to use for making assessments.[RFC4408], [RFC4406] and | |||
message content (e.g. [RFC4406] and [RFC4407]). The IP Address is | [RFC4407] The IP Address is obtained via underlying Internet | |||
obtained via underlying Internet information mechanisms and is | information mechanisms and is therefore trusted to be accurate. | |||
therefore trusted to be accurate. Besides having some known security | ||||
weaknesses, the use of addresses presents a number of functional and | Besides having some known security weaknesses, the use of addresses | |||
operational problems. Consequently there is a widespread desire to | presents a number of functional and operational problems. | |||
use an identifier that has better correspondence to organizational | Consequently there is a widespread desire to use an identifier that | |||
boundaries. Domain names are viewed as often satisfying this need. | has better correspondence to organizational boundaries. Domain names | |||
often are viewed as satisfying this need. | ||||
There have been four previous IETF efforts at standardizing an | There have been four previous IETF efforts at standardizing an | |||
Internet email signature scheme. Their goals have differed from | Internet email signature scheme. Their goals have differed from | |||
those of DKIM. | those of DKIM. | |||
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 | |||
skipping to change at page 5, line 26 | skipping to change at page 5, line 36 | |||
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 both S/MIME and OpenPGP has continued. While each has | Development of both S/MIME and OpenPGP has continued. While each has | |||
achieved a significant user base, neither one has achieved ubiquity | achieved a significant user base, neither one has achieved ubiquity | |||
in deployment or use. | in deployment or use. | |||
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 only uses cryptographic | |||
components that have a long history, including use within some of | mechanisms 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 management scheme, 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) [Kohnfelder] or Zimmermann (web of trust). For | of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust) | |||
DKIM, the owner of a domain name asserts the validity of a key, | [WebofTrust]. For DKIM, the owner of a domain name asserts the | |||
rather than relying on the key having a broader semantic implication | validity of a key, rather than having the validity of the key | |||
of the assertion, such as a quality assessment of the key's owner. | attested to by a trusted third party, often including other | |||
DKIM treats quality assessment as an independent, value-added | assertions, such as a quality assessment of the key's owner. DKIM | |||
service, beyond the initial work of deploying a verifying signature | treats quality assessment as an independent, value-added service, | |||
service. | beyond the initial work of deploying a verifying signature service. | |||
Further, DKIM's PKI is provided by adding information records to the | Further, DKIM's key management is provided by adding information | |||
existing Domain Name System (DNS) [RFC1034], rather than requiring | records to the existing Domain Name System (DNS) [RFC1034], rather | |||
deployment of a new query infrastructure. This approach has | than requiring deployment of a new query infrastructure. This | |||
significant operational advantages. First, it avoids the | approach has significant operational advantages. First, it avoids | |||
considerable barrier of creating a new global infrastructure; hence | the considerable barrier of creating a new global infrastructure; | |||
it leverages a global base of administrative experience and highly | hence it leverages a global base of administrative experience and | |||
reliable distributed operation. Second, the technical aspect of the | highly reliable distributed operation. Second, the technical aspect | |||
DNS is already known to be efficient. Any new service would have to | of the DNS is already known to be efficient. Any new service would | |||
undergo a period of gradual maturation, with potentially problematic | have to undergo a period of gradual maturation, with potentially | |||
early-stage behaviors. By (re-)using the DNS, DKIM avoids these | problematic early-stage behaviors. By (re-)using the DNS, DKIM | |||
growing pains. | avoids these growing pains. | |||
1.3. Internet Mail Background | 1.3. Internet Mail Background | |||
The basic Internet Email service has evolved extensively over its | The basic Internet Email service has evolved extensively over its | |||
several decades of continuous operation. Its modern architecture | several decades of continuous operation. Its modern architecture | |||
comprises a number of specialized components. A discussion about | comprises a number of specialized components. A discussion about | |||
Mail User Agents (MUA), Mail Handling Services (MHS), Mail Transfer | Mail User Agents (MUA), Mail Handling Services (MHS), Mail Transfer | |||
Agents (MTA), Mail Submission Agents (MSA), Mail Delivery Agents | Agents (MTA), Mail Submission Agents (MSA), Mail Delivery Agents | |||
(MDA), Mail Service Providers (MSP), Administrative Management | (MDA), Mail Service Providers (MSP), Administrative Management | |||
Domains (ADMDs), and their relationships can be found in Appendix A. | Domains (ADMDs), and their relationships can be found in Appendix A. | |||
1.4. Discussion Venue | 1.4. 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. | |||
This document is being discussed on the DKIM mailing list, | This document is being discussed on the DKIM mailing list, | |||
ietf-dkim@mipassoc.org. | ietf-dkim@mipassoc.org. | |||
1.4.1. Changes to document | ||||
In addition to simple wordsmithing, the following substantive changes | ||||
were made: | ||||
Service Arch figure and text: (per Allman) Existing figure and text | ||||
carries vestigial references to role of MSA and MDA. New text | ||||
switches focus to ADMD more completely and merely cites possible | ||||
functional modules within them. | ||||
2. The DKIM Value Proposition | 2. The DKIM Value Proposition | |||
The nature and origins of a message are often falsely stated. Such | The nature and origins of a message often are falsely stated. Such | |||
misrepresentations may (but not necessarily) be employed in order to | misrepresentations may be employed for legitimate reasons or for | |||
perpetrate abuse. DKIM provides a foundation for distinguishing | nefarious reasons.. DKIM provides a foundation for distinguishing | |||
legitimate mail, and thus a means of associating a verifiable | legitimate mail, and thus a means of associating a verifiable | |||
identifier with a message. Given the presence of that identifier, a | identifier with a message. Given the presence of that identifier, a | |||
receiver can make decisions about further handling of the message, | receiver can make decisions about further handling of the message, | |||
based upon assessments of the identity that is associated with the | based upon assessments of the identity that is associated with the | |||
identifier. | identifier. | |||
Receivers who successfully verify a signature can use information | Receivers who successfully verify a signature can use information | |||
about the signer as part of a program to limit spam, spoofing, | about the signer as part of a program to limit spam, spoofing, | |||
phishing, or other undesirable behavior. DKIM does not, itself, | phishing, or other undesirable behavior. DKIM does not, itself, | |||
prescribe any specific actions by the recipient; rather it is an | prescribe any specific actions by the recipient; rather it is an | |||
enabling technology for services that do. | enabling technology for services that do. | |||
These services will typically: | These services will typically: | |||
1. Determine a verified identity, if possible. | 1. Determine a verified identity as taking responsibility for the | |||
message, if possible. | ||||
2. Determine whether a known identity is trusted. | 2. Evaluate the trustworthiness of this/these identities. | |||
The role of DKIM is to perform the first of these; DKIM is an enabler | The role of DKIM is to perform the first of these; DKIM is an enabler | |||
for the second. | for the second. | |||
2.1. Identity Verification | 2.1. Identity Verification | |||
Consider an attack made against an organization or against customers | Consider an attack made against an organization or against customers | |||
of an organization. The name of the organization is linked to | of an organization. The name of the organization is linked to | |||
particular Internet domain names (identifiers). One point of | particular Internet domain names (identifiers). Attackers can | |||
leverage for attackers is either to use a legitimate domain name, | leverage either using a legitimate domain name, without | |||
without authorization, or to use a "cousin" name that is similar to | authorization, or using a "cousin" name that is similar to one that | |||
one that is legitimate, but is not controlled by the target | is legitimate, but is not controlled by the target organization. An | |||
organization. An assessment service that uses DKIM can differentiate | assessment service that uses DKIM can differentiate between domains | |||
between domains used by known organizations and domains used by | used by known organizations and domains used by others. As such, | |||
others. As such, DKIM performs the positive step of identifying | DKIM performs the positive step of identifying messages associated | |||
messages associated with verifiable identities, rather than the | with verifiable identities, rather than the negative step of | |||
negative step of identifying messages with problematic use of | identifying messages with problematic use of identities. Whether a | |||
identities. Whether a verified identity belongs to a Good Actor or a | verified identity belongs to a Good Actor or a Bad Actor is a | |||
Bad Actor becomes a later step of assessment. | question for later stages of assessment. | |||
2.2. Enabling Trust Assessments | 2.2. Enabling Trust Assessments | |||
Email receiving services are faced with a basic decision: Should they | Email receiving services are faced with a basic decision: Whether to | |||
deliver a newly-arrived message to the indicated recipient? That is, | deliver a newly-arrived message to the indicated recipient? That is, | |||
does the receiving service trust that the message is sufficiently | does the receiving service trust that the message is sufficiently | |||
"safe" to be viewed? For the modern Internet, most receiving | "safe" to be viewed? For the modern Internet, most receiving | |||
services have an elaborate engine that formulates this quality | services have an elaborate engine that formulates this quality | |||
assessment. These engines take a variety of information as input to | assessment. These engines take a variety of information as input to | |||
the decision, such as from reputation lists and accreditation | the decision, such as from reputation lists and accreditation | |||
services. As the engine processes information, it raises or lowers | services. As the engine processes information, it raises or lowers | |||
its trust assessment for the message. | its trust assessment for the message. | |||
DKIM provides additional information to this process by declaring a | In order to formulate reputation information, an accurate, stable | |||
valid "responsible" identity about which the engine can make quality | identifier is needed. Otherwise, the information might not pertain | |||
assessments. By itself, a valid DKIM signature neither lowers nor | to the identified organization's own actions. When using an IP | |||
raises the level of trust associated with the message, but it enables | Address, accuracy is based on the belief that the underlying Internet | |||
other mechanisms to be used for doing so. | infrastructure supplies an accurate address. When using domain based | |||
reputation data, some other for of validation is needed, since it is | ||||
not supplied independently by the infrastructure | ||||
DKIM satisfies this requirement by declaring a valid "responsible" | ||||
identity about which the engine can make quality assessments and by | ||||
using a digital signature to ensure that use of the identifier is | ||||
authorized. However by itself, a valid DKIM signature neither lowers | ||||
nor raises the level of trust associated with the message, but it | ||||
enables other mechanisms to be used for doing so. | ||||
An organization might build upon its use of DKIM by publishing | An organization might build upon its use of DKIM by publishing | |||
information about its Signing Practices (SP). This could permit | information about its Signing Practices (SP). This could permit | |||
detecting some messages that purport to be associated with a domain, | detecting some messages that purport to be associated with a domain, | |||
but which are not. As such, an SP can cause the trust assessment to | but which are not. As such, an SP can cause the trust assessment to | |||
be reduced, or leave it unchanged. | be reduced, or leave it unchanged. | |||
2.3. Establishing Message Validity | ||||
Though man-in-the-middle attacks are historically rare in email, it | ||||
is nevertheless theoretically possible for a message to be modified | ||||
during transit. An interesting side effect of the cryptographic | ||||
method used by DKIM is that it is possible to be certain that a | ||||
signed message (or, if l= is used, the signed portion of a message) | ||||
has not been modified. If it has been changed in any way, then the | ||||
message will not be verified successfully with DKIM. | ||||
As described above, this validity neither lowers nor raises the level | ||||
of trust associated with the message. If it was an untrustworthy | ||||
message when initially sent, the verifier can be certain that the | ||||
message will be equally untrustworthy upon receipt and successful | ||||
verification. | ||||
3. DKIM Goals | 3. DKIM Goals | |||
DKIM adds an end-to-end authentication mechanism to the existing | DKIM adds an end-to-end authentication capability to the existing | |||
email transfer infrastructure. This motivates functional goals about | email transfer infrastructure. It defines a mechanism that only | |||
the authentication itself and operational goals about its integration | needs to be supported by the signer and the validator, rather than | |||
with the rest of the Internet email service. | any of the functional components along the handling path. This | |||
motivates functional goals about the authentication itself and | ||||
operational goals about its integration with the rest of the Internet | ||||
email service. | ||||
3.1. Functional Goals | 3.1. Functional Goals | |||
3.1.1. Use Domain-level granularity for assurance | 3.1.1. Use Domain-level granularity for assurance | |||
DKIM seeks accountability at the coarse granularity of an | DKIM provides accountability at the coarse granularity of an | |||
organization or, perhaps, a department. An existing Internet service | organization or, perhaps, a department. An existing construct that | |||
construct that enables this granularity is the Domain Name [RFC1034]. | enables this granularity is the Domain Name [RFC1034]. DKIM binds a | |||
DKIM binds the signing key record to the Domain Name. Further | signing key record to the Domain Name. Further benefits of using | |||
benefits of using domain names include simplifying key management, | domain names include simplifying key management, enabling signing by | |||
enabling signing by the infrastructure as opposed to the MUA, and | the infrastructure as opposed to the MUA, and reducing privacy | |||
potential privacy issues. | concerns. | |||
Contrast this with OpenPGP and S/MIME, which provide end-to-end | Contrast this with OpenPGP and S/MIME, which associate validation | |||
validation in terms of individual authors, notably using full email | with individual authors, using their using full email addresses. | |||
addresses. | ||||
3.1.2. Implementation Locality | 3.1.2. Implementation Locality | |||
Any party, anywhere along the transit path can implement DKIM | Any party, anywhere along the transit path can implement DKIM | |||
signing. Its use is not confined to the end systems or only in a | signing. Its use is not confined to particular systems, such as the | |||
boundary MTA. | author's MUA or the inbound boundary MTA, and there can be more than | |||
one signature per message. | ||||
3.1.3. Allow delegation of signing to independent parties | 3.1.3. 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 was designed to | primarily visible to operators of the service. DKIM was designed to | |||
support signing by any of these different parties and to permit them | support signing by any of these different parties and to permit them | |||
to sign with any domain name that they deem appropriate (and for | to sign with any domain name that they deem appropriate (and for | |||
which they hold authorized signing keys.) As an example an | which they hold authorized signing keys.) As an example an | |||
organization that creates email content often delegates portions of | organization that creates email content often delegates portions of | |||
its processing or transmission to an outsourced group. DKIM supports | its processing or transmission to an outsourced group. DKIM supports | |||
this mode of activity, in a manner that is not normally visible to | this mode of activity, in a manner that is not normally visible to | |||
end users. | end users. Similarly, a reputation provider can delegate a signing | |||
key for a domain under the control of the provider, to be used by an | ||||
organization the provider is prepared to vouch for. | ||||
3.1.4. Distinguish the core authentication mechanism from its | 3.1.4. 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 assessment | |||
policies, either ad hoc or standardized. The only semantics inherent | policies, either ad hoc or standardized. DKIM separates basic | |||
to a DKIM signature is that the signer is asserting (some) | authentication from assessment. The only semantics inherent to a | |||
responsibility for the message. All other mechanisms and meanings | DKIM signature is that the signer is asserting (some) responsibility | |||
are built on this core service. One such mechanism might assert a | for the message. Hence, a DKIM signature only means that the signer | |||
relationship between the signing identity and the author, as | is asserting (some) responsibility for the message, and nothing more. | |||
Other services can build upon this core association, but their | ||||
details are beyond the scope of that core. 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]. | specified in the From: header field's domain identity[RFC2822]. | |||
Another might specify how to treat an unsigned message with that | Another might specify how to treat an unsigned message with that | |||
From: field domain. | From: field domain. | |||
3.1.5. Retain ability to have anonymous email | 3.1.5. 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 authentication of the email system operator, rather than the | permits authentication of the email system operator, rather than the | |||
content author. If it is possible to obtain effectively anonymous | content author. If it is possible to obtain effectively anonymous | |||
accounts at example.com, knowing that a message definitely came from | accounts at example.com, 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. | it. | |||
3.2. Operational Goals | 3.2. Operational Goals | |||
3.2.1. Treat verification failure the same as no signature present | 3.2.1. Make presence of signature transparent to non-supporting | |||
recipients | ||||
As a sub-goal to the requirement for transparency, a DKIM signature | ||||
verifier is to treat messages with signatures that fail as if they | ||||
were unsigned. Hence the message will revert to normal handling, | ||||
through the receiver's existing filtering mechanisms. Thus, DKIM | ||||
specifies that an assessing site is not to take a message that has a | ||||
broken signature and treat it any differently than if the signature | ||||
weren't there. | ||||
Contrast this with OpenPGP and S/MIME, which were designed for strong | ||||
cryptographic protection. This included treating verification | ||||
failure as message failure. | ||||
3.2.2. Make signatures transparent to non-supporting recipients | ||||
In order to facilitate incremental adoption, DKIM is designed to be | In order to facilitate incremental adoption, DKIM is designed to be | |||
transparent to recipients that do not support it. A DKIM signature | transparent to recipients that do not support it. A DKIM signature | |||
does not "get in the way" for such recipients. | does not "get in the way" for such recipients. | |||
Contrast this with S/MIME and OpenPGP, which modify the message body. | Contrast this with S/MIME and OpenPGP, which modify the message body. | |||
Hence, their presence is potentially visible to email recipients, | Hence, their presence is potentially visible to email recipients, | |||
whose user software needs to process the associated constructs. | whose user software needs to process the associated constructs. | |||
3.2.2. Treat verification failure the same as no signature present | ||||
DKIM must also be transparent to existing assessment mechanisms. | ||||
Consequently, a DKIM signature verifier is to treat messages with | ||||
signatures that fail as if they were unsigned. Hence the message | ||||
will revert to normal handling, through the receiver's existing | ||||
filtering mechanisms. Thus, DKIM specifies that an assessing site is | ||||
not to take a message that has a broken signature and treat it any | ||||
differently than if the signature weren't there. | ||||
Contrast this with OpenPGP and S/MIME, which were designed for strong | ||||
cryptographic protection. This included treating verification | ||||
failure as message failure. | ||||
3.2.3. Permit incremental adoption for incremental benefit | 3.2.3. Permit incremental adoption for incremental benefit | |||
DKIM can immediately provide benefits between any two organizations | DKIM can be used by any two organizations that exchange email and | |||
that exchange email and implement DKIM. In the usual manner of | implement DKIM; it does not require adoption within the open | |||
"network effects", the benefits of DKIM increase dramatically as its | Internet's email infrastructure. In the usual manner of "network | |||
adoption increases. | effects", the benefits of DKIM increase as its adoption increases. | |||
Although it is envisioned that this mechanism will call upon | Although this mechanism can be used in association with independent | |||
independent services to aid in the assessment of DKIM results, they | assessment services, such services are not essential in order to | |||
are not essential in order to obtain initial benefit. For example | obtain initial benefit. For example DKIM allows (possibly large) | |||
DKIM allows (possibly large) pair-wise sets of email providers and | pairwise sets of email providers and spam filtering companies to | |||
spam filtering companies to distinguish mail that is associated with | distinguish mail that is associated with a known organization from | |||
a known organization from mail that might deceptively purport to have | mail that might deceptively purport to have the affiliation. This in | |||
the affiliation. This in turn allows the development of "whitelist" | turn allows the development of "whitelist" schemes whereby | |||
schemes whereby authenticated mail from a known source with good | authenticated mail from a known source with good reputation is | |||
reputation is allowed to bypass some anti-abuse filters. | 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. | |||
Management of email deliverability problems currently represents a | Management of email delivery problems currently represents a | |||
significant pain point for email administrators at every point on the | significant pain point for email administrators at every point on the | |||
mail transit path. Administrators who have deployed DKIM | mail transit path. Administrators who have deployed DKIM | |||
verification have an incentive to evangelize the use of DKIM | verification have an incentive to evangelize the use of DKIM | |||
signatures to senders who may subsequently complain that their email | signatures to senders who might subsequently complain that their | |||
is not being delivered. | email is not being delivered. | |||
3.2.4. Minimize the amount of required infrastructure | 3.2.4. Minimize the amount of required infrastructure | |||
A new service, or an enhancement to an existing service, requires | In order to allow early adopters to gain early benefit, DKIM makes no | |||
adoption in a critical mass of system components, before it can be | changes to the core Internet Mail service and, instead, can provide a | |||
useful. The greater the number of required adopters, the higher the | useful benefit for any individual pair of signers and verifiers who | |||
adoption barrier. This becomes particularly serious when adoption is | are exchanging mail. Similarly, DKIM's reliance on the Domain Name | |||
required by independent, intermediary -- that is, infrastructure -- | System greatly reduces the amount of new administrative | |||
service providers. In order to allow early adopters to gain early | infrastructure that is needed across the open Internet. | |||
benefit, DKIM makes no changes to the core Internet Mail service and, | ||||
instead, can provide a useful benefit for any individual pair of | ||||
signers and verifiers who are exchanging mail. Similarly, DKIM's | ||||
reliance on the Domain Name System greatly reduces the amount of new | ||||
administrative infrastructure that is needed across the open | ||||
Internet. | ||||
3.2.5. Permit wide range of deployment choices | 3.2.5. Permit a 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 affords flexibility in terms of who administers | |||
how little they want DKIM to be part of their service, rather than | its use, as well as what traffic carries a DKIM signature. For | |||
part of a more localized operation. | example, employing DKIM at an outbound boundary MTA will mean that it | |||
is administered by the organization's central IT department and that | ||||
internal messages are not signed. | ||||
4. DKIM Function | 4. 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 does not | message, especially a responsible identity. When a message does not | |||
have a valid signature associated with the author, DKIM SP will | have a valid signature associated with the author, DKIM SP will | |||
permit the domain name of the author to be used for obtaining | permit the domain name of the author to be used for obtaining | |||
information about their signing practices. | information about their signing practices. | |||
4.1. The Basic Signing Service | 4.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 adds the signature information using a DKIM header | |||
verifier obtains the domain name and the "selector" from the DKIM | field. A verifier obtains the domain name and the "selector" from | |||
header field, queries for a public key associated with the name, and | the DKIM header field, obtains the public key associated with the | |||
verifies the signature. | name, and 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. | interoperability. | |||
DKIM permits restricting the use of a signature key (by using s=) to | DKIM permits restricting the use of a signature key to signing | |||
signing messages for particular types of services, such as only for | messages for particular types of services, such as only for a single | |||
email. This is intended to be helpful when delegating signing | source of email. This is intended to be helpful when delegating | |||
authority, such as to a particular department or to a third-party | signing authority, such as to a particular department or to a third- | |||
outsourcing service. | 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, | |||
such as From:, Date: and Subject:. By choosing the minimal set of | such as From:, Date: and Subject:. By choosing the minimal set of | |||
headers needed, the signature is likely to be considerably more | headers needed, the signature is likely to be considerably more | |||
robust against the handling vagaries of intermediary MTAs. | robust against the handling vagaries of intermediary MTAs. | |||
4.2. Characteristics of a DKIM signature | 4.2. Characteristics of a DKIM signature | |||
A DKIM signature covers the message body and selected header fields. | A DKIM signature applies to the message body and selected header | |||
The signer computes a hash of the selected header fields and another | fields. The signer computes a hash of the selected header fields and | |||
hash of the body. The signer then uses a private key to | another 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 the DKIM-Signature | parameters. Signature information is placed into the DKIM-Signature | |||
header field, a new [RFC2822] header field of the message. | header field, a new [RFC2822] header field of the message. | |||
4.3. The Selector construct | 4.3. The Selector construct | |||
The key for a signature is associated with a domain name, as | The key for a signature is associated with a domain name. That | |||
specified in the d= parameter of the DKIM-Signature header. That | domain name provides the complete identity used for making | |||
domain name, or the domain name or address in the i= parameter, | assessments about the signer. (The DKIM specification does not give | |||
provide the complete identity used for making assessments about the | any guidance on how to do an assessment.) However this name is not | |||
signer. (The DKIM specification does not give any guidance on how to | sufficient for making a DNS query to obtain the key needed to verify | |||
do an assessment.) However this name is not sufficient for making a | the signature. | |||
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 | |||
potential signers. To support this, DKIM identifies a particular | potential signers. To support this, DKIM identifies a particular | |||
signature as a combination of the domain name and an added field, | signature as a combination of the domain name and an added field, | |||
called the "selector", specified in separate DKIM-Signature header | called the "selector", specified in a separate DKIM-Signature header | |||
field parameters. | field parameter. | |||
NOTE: The semantics of the selector (if any) are strictly reserved | NOTE: The semantics of the selector (if any) are strictly reserved | |||
to the signer and should be treated as an opaque string by all | to the signer and is to be treated as an opaque string by all | |||
other parties. If verifiers were to employ the selector as part | other parties. If verifiers were to employ the selector as part | |||
of a name assessment mechanism, then there would be no remaining | of a name assessment mechanism, then there would be no remaining | |||
mechanism for making a transition from an old, or compromised, key | mechanism for making a transition from an old, or compromised, key | |||
to a new one. | to a new 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". This is (or | |||
can be) entirely separate from the From: header field domain. | ||||
4.4. Verification | 4.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 signed to by a party in possession of the private key for | |||
for the signing domain. Typically, verification will be done by an | the signing domain. Typically, verification will be done by an agent | |||
agent in the Administrative Management Domain (ADMD) of the message | in the Administrative Management Domain (ADMD) of the message | |||
recipient. | recipient. | |||
5. Service Architecture | 5. Service Architecture | |||
DKIM use external service components, such as for key retrieval and | ||||
The DKIM service is divided into components that are performed using | relaying email. This specification defines an initial set, using DNS | |||
different, external services, such as for key retrieval and relaying | and SMTP, for basic interoperability. | |||
email. The basic DKIM signing specification defines an initial set | ||||
of these services (using DNS and SMTP), in order to ensure a basic | ||||
level of interoperability. | ||||
| | | | |||
|- RFC2822 Message | |- RFC2822 Message | |||
V | V | |||
+--------+ +------------------------------------+ | +--------+ +--------------------------------+ | |||
| Private| | ORIGINATING OR RELAYING ADMD (MSA) | | | Private| | ORIGINATING OR RELAYING ADMD | | |||
| Key |.>| Sign Message | | | Key +...>| Sign Message | | |||
| Store | +--------------+---------------------+ | | Store | +---------------+----------------+ | |||
+--------+ | | +--------+ | | |||
(paired) | | (paired) | | |||
+--------+ | +-----------+ | +--------+ | +-----------+ | |||
| Public | | | Remote | | | Public | | | Remote | | |||
| Key | [Internet] | Sender | | | Key | [Internet] | Sender | | |||
| Store | | | Practices | | | Store | | | Practices | | |||
+----+---+ | +-----+-----+ | +----+---+ | +-----+-----+ | |||
. V . | . V . | |||
. +-----------------------------------+ . | . +--------------------------------+ . | |||
. | RELAYING OR DELIVERING ADMD (MDA) | . | . | RELAYING OR DELIVERING ADMD | . | |||
. | Message Signed? | . | . | Message Signed? | . | |||
. +--------+---------------+----------+ . | . +-----+-----------------+--------+ . | |||
. |yes |no . | . |yes |no . | |||
. V | . | . V | . | |||
. +------------+ | . | . +-------------+ | . | |||
+.....>| Verify +----+ | . | +.......>| Verify +-----+ | . | |||
| Signatures | | | . | | Signature | | | . | |||
+-----+------+ | | . | +------+------+ | | . | |||
pass| fail| | . | pass| fail| | . | |||
V | | . | V | | . | |||
+--------+ | | . | +-------------+ | | . | |||
+.......>| Assess | | | . | | | | | . | |||
. | Signer | V V . | +.......>| Assessments | | | . | |||
. +---+----+ +-------+ . | . | | V V . | |||
. | / Check \<............+ | . +------+------+ +-------+ . | |||
. +------>/ Signing \ | . | / Check \<...........+ | |||
. | / Practices \<..........+ | . +------->/ Signing \ | |||
. | / Practices \<.........+ | ||||
. | +-------+-------+ . | . | +-------+-------+ . | |||
. | | . | . | | . | |||
. | V . | . | V . | |||
+---+---------+ | +-----------+ +------+-----+ | +----+--------+ | +-----------+ +------+-----+ | |||
|Reputation/ | | | Message | | Local Info | | |Reputation/ | | | Message | | Local Info | | |||
|Accreditation| +------>| Filtering | | on Sender | | |Accreditation| +------->| Filtering | | on Sender | | |||
|Info | | Engine | | Practices | | |Info | | Engine | | Practices | | |||
+-------------+ +-----------+ +------------+ | +-------------+ +-----------+ +------------+ | |||
Figure 1: DKIM Service Architecture | Figure 1: DKIM Service Architecture | |||
As shown in Figure 1, basic message processing is divided between a | ||||
signing Administrative Management Domain (ADMD) and a validating | ||||
ADMD. At its simplest, this is between the Originating ADMD and the | ||||
delivering ADMD, but can involve other ADMDs in the handling path. | ||||
As shown in Figure 1, basic message processing is divided between the | Signing: Signing is performed by an authorized module within the | |||
MSA and the MDA. | signing ADMD and uses private information from the Key Store, as | |||
discussed below. Within the originating ADMD, this might be | ||||
The MSA The MSA signs the message, using private information from | performed by the MUA, MSA or an MTA. | |||
the Key Store. | ||||
The MDA The MDA verifies the signature or determines whether a | Validating: Validating is performed by an authorized module within | |||
signature was required. Verifying the signature uses public | the validating ADMD. Within a delivering ADMD, validating might | |||
information from the Key Store. If the signature passes, | be performed by an MTA, MDA or MUA. The module verifies the | |||
reputation information is used to asses the signer and that | signature or determines whether a signature was required. | |||
information is passed to the message filtering system. If the | Verifying the signature uses public information from the Key | |||
signature fails or there is no signature, information about the | Store. If the signature passes, reputation information is used to | |||
related signing practices is retrieved remotely and/or locally, | asses the signer and that information is passed to the message | |||
filtering system. If the signature fails or there is no signature | ||||
using the author's domain, information about signing practices | ||||
related to the author can be retrieved remotely and/or locally, | ||||
and that information is passed to the message filtering system. | and that information is passed to the message filtering system. | |||
Note: Figure 1 does not show the effects on the message handling | Note: If message has more than one valid signature, the order in | |||
when multiple signatures or non-author signatures are present. | which the signers are assessed and the interactions among the | |||
assessments are not defined in this document. | ||||
5.1. Administration and Maintenance | 5.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 cryptography. | Key Store DKIM uses public/private (asymmetric) key cryptography. | |||
The signer users a private key and the validator uses the | 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 | |||
therefore must have a means of adding a key to the DNS, for every | therefore needs to have a means of adding a key to the DNS, for | |||
selector/domain-name combination. Further, the signing | every selector/domain-name combination. Further, the signing | |||
organization needs policies for distributing and revising keys. | organization needs policies for distributing and revising keys. | |||
Reputation/Accreditation If a message contains a valid signature, | Reputation/Accreditation If a message contains a valid signature, | |||
then the verifier can evaluate the associated domain name's | then the verifier can evaluate the associated domain name's | |||
reputation. Quality-assessment information, which is associated | reputation, in order to determine appropriate delivery or display | |||
with a domain name, comes in many forms and from many sources. | options for that message. Quality-assessment information, which | |||
DKIM does not define assessment services. It's relevance to them | is associated with a domain name, comes in many forms and from | |||
is to provide a validated domain name, upon which assessments can | many sources. DKIM does not define assessment services. It's | |||
be made. | relevance to them is to provide a validated domain name, upon | |||
which assessments can be made. | ||||
Signing Practices (SP) Separate from determining the validity of a | Signing Practices (SP) Separate from determining the validity of a | |||
signature, and separate from assessing the reputation of the | signature, and separate from assessing the reputation of the | |||
organization that is associated with the signed identity, there is | organization that is associated with the signed identity, there is | |||
an the opportunity to determine any organizational practices | an the opportunity to determine any organizational practices | |||
concerning a domain name. Practices can range widely. They can | concerning a domain name. Practices can range widely. They can | |||
be published by the owner of the domain or they can be maintained | be published by the owner of the domain or they can be maintained | |||
by the evaluating site. They can pertain to the use of the domain | by the evaluating site. They can pertain to the use of the domain | |||
name, such as whether it is used for signing messages, whether all | name, such as whether it is used for signing messages, whether all | |||
mail having that domain name in the author From: header field is | mail having that domain name in the author From: header field is | |||
signed, or whether such mail is to be discarded in the absence of | signed, or even whether the domain owner recommends discarding | |||
an appropriate signature. The statements of practice are made at | messages in the absence of an appropriate signature. The | |||
the level of a domain name, and are distinct from assessments made | statements of practice are made at the level of a domain name, and | |||
about particular messages, as occur in a Message Filtering Engine. | are distinct from assessments made about particular messages, as | |||
Such assessments of practices can provide useful input for the | occur in a Message Filtering Engine. Such assessments of | |||
Message Filtering Engine's determination of message handling. As | practices can provide useful input for the Message Filtering | |||
practices are defined, each domain name owner needs to consider | Engine's determination of message handling. As practices are | |||
what information to publish. The nature and degree of checking | defined, each domain name owner needs to consider what information | |||
practices, if any is performed, is optional to the evaluating site | to publish. The nature and degree of checking practices, if any | |||
and is strictly a matter of local policy. | is performed, is optional to the evaluating site and is strictly a | |||
matter of local policy. | ||||
5.2. Signing | 5.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. | |||
5.3. Verifying | 5.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. | |||
5.4. Unverified or Unsigned Mail | 5.4. Unverified or Unsigned Mail | |||
Note that a failed signature causes the message to be treated in the | Messages lacking a valid author signature (a signature associated | |||
same manner as one that is unsigned. Messages lacking a valid author | with the author of the message as opposed to a signature associated | |||
signature (a signature associated with the author of the message as | with an intermediary) can prompt a query for any published "signing | |||
opposed to a signature associated with an intermediary) can prompt a | practices" information, as an aid in determining whether the author | |||
query for any published "signing practices" information, as an aid in | information has been used without authorization. | |||
determining whether the author information has been used without | ||||
authorization. | ||||
5.5. Assessing | 5.5. Assessing | |||
Figure 1 shows the verified identity as being used to assess an | Figure 1 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 the scope of DKIM, other than the expectation | details are outside of the scope of DKIM, other than the expectation | |||
that the validated identity produced by DKIM will be added to the | that the validated identity produced by DKIM can accumulate its own | |||
varied soup of rules used by the engines. The rules can cover signed | reputation, and will be added to the varied soup of rules used by the | |||
messages and can deal with unsigned messages from a domain, if the | engines. The rules can cover signed messages and can deal with | |||
domain has published information about its practices. | unsigned messages from a domain, if the domain has published | |||
information about its practices. | ||||
5.6. DKIM Placement within an ADMD | 5.6. 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 authoring organization's | will be within the infrastructures of the authoring organization's | |||
outbound service and the receiving organization's inbound service, | outbound service and the receiving organization's inbound service, | |||
such as a department or a boundary MTA. DKIM can be implemented in | 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 | an author's or recipient MUA, but this is expected to be less | |||
typical, since it has higher administration and support costs. | typical, since it has higher administration and support costs. | |||
A Mediator, such as a mailing list, often can re-post a message | A Mediator is an MUA that receives a message and can re-post a | |||
without breaking the DKIM signature. Furthermore it can add its own | modified version of it, such as to a mailing list. A DKIM signature | |||
signature. This can be added by the Mediator software itself, or by | can survive some types of modifications through this process. | |||
any outbound component in the Mediator's ADMD. | Furthermore the Mediator can add its own signature. This can be | |||
added by the Mediator software itself, or by any outbound component | ||||
in the Mediator's ADMD. | ||||
6. Security Considerations | 6. Security Considerations | |||
The security considerations of the DKIM protocol are described in the | The security considerations of the DKIM protocol are described in the | |||
DKIM base specification [RFC4871]. | DKIM base specification [RFC4871]. | |||
7. IANA Considerations | 7. IANA Considerations | |||
There are no actions for IANA. | There are no actions for IANA. | |||
NOTE TO RFC EDITOR: This section may be removed prior to | NOTE TO RFC EDITOR: This section is to be removed prior to | |||
publication. | publication. | |||
8. Acknowledgements | 8. Acknowledgements | |||
Many people contributed to the development of the DomainKeys | Many people contributed to the development of the DomainKeys | |||
Identified Mail and the efforts of the DKIM Working Group is | Identified Mail and the efforts of the DKIM Working Group is | |||
gratefully acknowledged. In particular, we would like to thank Jim | gratefully acknowledged. In particular, we would like to thank Jim | |||
Fenton for his extensive feedback diligently provided on every | Fenton for his extensive feedback diligently provided on every | |||
version of this document. | version of this document. | |||
9. Informative References | 9. Informative References | |||
[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-11 (work in progress), | draft-kucherawy-sender-auth-header-15 (work in progress), | |||
February 2008. | July 2008. | |||
[Kohnfelder] | [Kohnfelder] | |||
Kohnfelder, L., "Towards a Practical Public-key | Kohnfelder, L., "Towards a Practical Public-key | |||
Cryptosystem", May 1978. | Cryptosystem", May 1978. | |||
[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", | |||
skipping to change at page 19, line 14 | skipping to change at page 19, line 24 | |||
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, | Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, | |||
May 2007. | May 2007. | |||
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | |||
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | |||
Signatures", RFC 4871, May 2007. | Signatures", RFC 4871, May 2007. | |||
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. | [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. | |||
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. | Thayer, "OpenPGP Message Format", RFC 4880, November 2007. | |||
[WebofTrust] | ||||
Wikipedia, "Web of Trust", | ||||
URL http://en.wikipedia.org/wiki/Web_of_trust, | ||||
<http://en.wikipedia.org/wiki/Web_of_trust>. | ||||
Appendix A. Internet Mail Background | Appendix A. Internet Mail Background | |||
A.1. Core Model | ||||
Internet Mail is split between the user world, in the form of Mail | Internet Mail is split between the user world, in the form of Mail | |||
User Agents (MUA), and the transmission world, in the form of the | User Agents (MUA), and the transmission world, in the form of the | |||
Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). | Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). | |||
The MHS is responsible for accepting a message from one user, the | The MHS is responsible for accepting a message from one user, the | |||
author, and delivering it to one or more other users, the recipients. | author, and delivering it to one or more other users, the recipients. | |||
This creates a virtual MUA-to-MUA exchange environment. The first | This creates a virtual MUA-to-MUA exchange environment. The first | |||
component of the MHS is called the Mail Submission Agent (MSA) and | component of the MHS is called the Mail Submission Agent (MSA) and | |||
the last is called the Mail Delivery Agent (MDA). | 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 re-posts it for further distribution, | delivery of a message, makes changes appropriate to its service, and | |||
retaining the original From: header field. A mailing list is a | then re-posts it for further distribution. Typically the new message | |||
will retain the original From: header field. A mailing list is a | ||||
common example of a Mediator. | common 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 elaborated 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. | |||
A.1. Administrative Management Domain (ADMD) | A.2. Trust Boundaries | |||
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. | |||
skipping to change at page 20, line 28 | skipping to change at page 21, line 8 | |||
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. | often is directly between the Edge ADMDs, at the email level. | |||
+--------+ +--------+ +--------+ | +--------+ +--------+ +--------+ | |||
| ADMD#1 | | ADMD#3 | | ADMD#4 | | | ADMD#1 | | ADMD#3 | | ADMD#4 | | |||
| ------ | | ------ | | ------ | | | ------ | | ------ | | ------ | | |||
| | +----------------------->| | | | | | | +----------------------->| | | | | |||
| User | | |--Edge--+--->|--User | | | User | | |--Edge--+--->|--User | | |||
| | | | +--->| | | | | | | | | +--->| | | | | |||
| V | | | +--------+ +--------+ | | V | | | +--------+ +--------+ | |||
| Edge---+---+ | | | Edge---+---+ | | |||
| | | +----------+ | | | | | +----------+ | | |||
+--------+ | | ADMD#2 | | | +--------+ | | ADMD#2 | | | |||
skipping to change at page 21, line 34 | skipping to change at page 22, line 13 | |||
turn, are used by one or more Relays and Users. It is not | turn, are used by one or more Relays and Users. It is not | |||
necessarily their job to perform email functions, but they | necessarily their job to perform email functions, but they | |||
can, instead, provide an environment in which those | can, instead, provide an environment in which those | |||
functions can be performed. | functions can be performed. | |||
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. | |||
Index | ||||
A | ||||
ADMD 6 | ||||
Administrative Management Domain 6 | ||||
assessment 7 | ||||
D | ||||
DNS 5, 12-15 | ||||
I | ||||
identifier 3-4, 6-7 | ||||
identity 3-4, 6-7, 9, 12 | ||||
infrastructure 5, 8-9, 11, 17 | ||||
M | ||||
Mail Delivery Agent 6 | ||||
Mail Handling Service 6 | ||||
Mail Service Provider 6 | ||||
Mail Submission Agent 6 | ||||
Mail Transfer Agent 6 | ||||
Mail User Agent 6 | ||||
MDA 6 | ||||
MHS 6 | ||||
MIME Object Security Services 5 | ||||
MOSS 5 | ||||
MSA 6 | ||||
MSP 6 | ||||
MTA 6 | ||||
MUA 6 | ||||
O | ||||
OpenPGP 5 | ||||
P | ||||
PEM 5 | ||||
PGP 5 | ||||
Pretty Good Privacy 5 | ||||
Privacy Enhanced Mail 5 | ||||
S | ||||
S/MIME 5 | ||||
T | ||||
trust 3, 7-8, 20 | ||||
V | ||||
verification 4, 7-8, 10-11, 13, 16, 20-21 | ||||
W | ||||
Web of Trust 5 | ||||
X | ||||
X.509 5 | ||||
Authors' Addresses | Authors' Addresses | |||
Tony Hansen | Tony Hansen | |||
AT&T Laboratories | AT&T Laboratories | |||
200 Laurel Ave. | 200 Laurel Ave. | |||
Middletown, NJ 07748 | Middletown, NJ 07748 | |||
USA | USA | |||
Email: tony+dkimov@maillennium.att.com | Email: tony+dkimov@maillennium.att.com | |||
Dave Crocker | Dave Crocker | |||
Brandenburg InternetWorking | Brandenburg InternetWorking | |||
675 Spruce Dr. | 675 Spruce Dr. | |||
Sunnyvale, CA 94086 | Sunnyvale, CA 94086 | |||
USA | USA | |||
Email: dcrocker@bbiw.net | Email: dcrocker@bbiw.net | |||
Phillip Hallam-Baker | Phillip Hallam-Baker | |||
VeriSign Inc. | VeriSign Inc. | |||
skipping to change at page 23, line 44 | skipping to change at line 1108 | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 80 change blocks. | ||||
289 lines changed or deleted | 412 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |