draft-ietf-dkim-deployment-10.txt   draft-ietf-dkim-deployment-11.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational E. Siegel Intended status: Informational E. Siegel
Expires: June 21, 2010 Expires: July 31, 2010
P. Hallam-Baker P. Hallam-Baker
Default Deny Security, Inc. Default Deny Security, Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
December 18, 2009 January 27, 2010
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-10 draft-ietf-dkim-deployment-11
Abstract Abstract
DomainKeys Identified Mail (DKIM) allows an organization to claim DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. The organization can be the author's, the validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. A originating sending site, an intermediary, or one of their agents. A
message can contain multiple signatures, from the same or different message can contain multiple signatures, from the same or different
organizations involved with the message. DKIM defines a domain-level organizations involved with the message. DKIM defines a domain-level
digital signature authentication framework for email, using public digital signature authentication framework for email, using public
key cryptography, using the domain name service as its key server key cryptography, using the domain name service as its key server
technology [RFC4871]. This permits verification of a responsible technology. This permits verification of a responsible organization,
organization, as well as the integrity of the message contents. DKIM as well as the integrity of the message contents. DKIM will also
will also provide a mechanism that permits potential email signers to provide a mechanism that permits potential email signers to publish
publish information about their email signing practices; this will information about their email signing practices; this will permit
permit email receivers to make additional assessments about messages. email receivers to make additional assessments about messages.
DKIM's authentication of email identity can assist in the global DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing". This document provides control of "spam" and "phishing". This document provides
implementation, deployment, operational and migration considerations implementation, deployment, operational and migration considerations
for DKIM. for DKIM.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 21, 2010. This Internet-Draft will expire on July 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Using DKIM as Part of Trust Assessment . . . . . . . . . . . . 5 2. Using DKIM as Part of Trust Assessment . . . . . . . . . . . . 5
2.1. A Systems View of Email Trust Assessment . . . . . . . . . 5 2.1. A Systems View of Email Trust Assessment . . . . . . . . . 5
2.2. Choosing a DKIM Tag for the Assessment Identifier . . . . 7 2.2. Choosing a DKIM Tag for the Assessment Identifier . . . . 7
2.3. Choosing the Signing Domain Name . . . . . . . . . . . . . 9 2.3. Choosing the Signing Domain Name . . . . . . . . . . . . . 9
2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11 2.4. Recipient-based Assessments . . . . . . . . . . . . . . . 11
2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 13
3. DKIM Key Generation, Storage, and Management . . . . . . . . . 14 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 16
3.1. Private Key Management: Deployment and Ongoing 3.1. Private Key Management: Deployment and Ongoing
Operations . . . . . . . . . . . . . . . . . . . . . . . . 15 Operations . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Storing Public Keys: DNS Server Software Considerations . 16 3.2. Storing Public Keys: DNS Server Software Considerations . 18
3.3. Per User Signing Key Management Issues . . . . . . . . . . 17 3.3. Per User Signing Key Management Issues . . . . . . . . . . 19
3.4. Third Party Signer Key Management and Selector 3.4. Third Party Signer Key Management and Selector
Administration . . . . . . . . . . . . . . . . . . . . . . 17 Administration . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 20
4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Signing Policies and Practices . . . . . . . . . . . . . . 21 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 23
5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 21 5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 24
5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 22 5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 24
5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 22 5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 24
5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 23 5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 25
5.5. Messages sent through Mailing Lists and other 5.5. Messages sent through Mailing Lists and other
Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23 Intermediaries . . . . . . . . . . . . . . . . . . . . . . 25
5.6. Generation, Transmission and Use of Results Headers . . . 23 5.6. Generation, Transmission and Use of Results Headers . . . 26
6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 24 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 26
6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 24 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 27
6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 25 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 27
6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 26 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 28
6.4. Using Trusted Third Party Senders . . . . . . . . . . . . 27 6.4. Using Trusted Third Party Senders . . . . . . . . . . . . 30
6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 28 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 30
7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 30 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 32
7.1. Author's Organization - Simple . . . . . . . . . . . . . . 30 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 32
7.2. Author's Organization - Differentiated Types of Mail . . . 30 7.2. Author's Organization - Differentiated Types of Mail . . . 33
7.3. Author Domain Signing Practices . . . . . . . . . . . . . 30 7.3. Author Domain Signing Practices . . . . . . . . . . . . . 33
7.4. Delegated Signing . . . . . . . . . . . . . . . . . . . . 32 7.4. Delegated Signing . . . . . . . . . . . . . . . . . . . . 35
7.5. Independent Third Party Service Providers . . . . . . . . 33 7.5. Independent Third Party Service Providers . . . . . . . . 35
7.6. Mail Streams Based on Behavioral Assessment . . . . . . . 33 7.6. Mail Streams Based on Behavioral Assessment . . . . . . . 36
7.7. Agent or Mediator Signatures . . . . . . . . . . . . . . . 34 7.7. Agent or Mediator Signatures . . . . . . . . . . . . . . . 37
8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 37
8.1. Non-standard Submission and Delivery Scenarios . . . . . . 34 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 37
8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 35 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 38
8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 36 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 38
8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 37 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 40
8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 41
9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 42
9.1. Security Considerations . . . . . . . . . . . . . . . . . 40 9.1. Security Considerations . . . . . . . . . . . . . . . . . 42
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 41 Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 43
A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 41 A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 44
A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 46 A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 48
A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 47 A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 49
Appendix B. General Coding Criteria for Cryptographic Appendix B. General Coding Criteria for Cryptographic
Applications . . . . . . . . . . . . . . . . . . . . 48 Applications . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) allows an organization to claim DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. This document provides practical tips for: validated by a recipient. This document provides practical tips for:
those who are developing DKIM software, mailing list managers, those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing DNS servers; those who are deploying DKIM software, keys, mailing
list software, and migrating from DomainKeys [RFC4870]; and those who list software, and migrating from DomainKeys [RFC4870]; and those who
skipping to change at page 13, line 7 skipping to change at page 13, line 7
its own reputation rating for the identifier(s). That is, over time, its own reputation rating for the identifier(s). That is, over time,
the Assessor can observe the stream of messages associated with the the Assessor can observe the stream of messages associated with the
identifier(s) developing a reaction to associated content. For identifier(s) developing a reaction to associated content. For
example, if there is a high percentage of user complaints regarding example, if there is a high percentage of user complaints regarding
signed mail with a "d=" value of "widgetco.example.net", the Assessor signed mail with a "d=" value of "widgetco.example.net", the Assessor
might include that fact in the vector of data it provides to the might include that fact in the vector of data it provides to the
Handling Filter. This is also discussed briefly in Section 5.4. Handling Filter. This is also discussed briefly in Section 5.4.
2.5. Filtering 2.5. Filtering
After assessing the signer of a message, each receiving site creates The assessment of the signing identifier is given to a Handling
and tunes its own Handling Filter according to criteria specific for Filter that is defined by local policies, according to a potentially
that site. Still, there are commonalities across sites, and this wide range of different factors and weightings. This section
section offers a discussion, rather than a specification, of some discusses some of the kinds of choices and weightings that are
types of input to that process and how they can be used. plausible, and the differential actions that might be performed.
Because authenticated domain names represent a collaborative sequence
between signer and assessor, actions can sometimes reasonably include
contacting the signer.
The discussion focuses on variations in Organizational Trust versus The discussion focuses on variations in Organizational Trust versus
Message Risk, that is, the degree of positive assessment of a DKIM- Message Stream Risk, that is, the degree of positive assessment of a
signing organization, and the potential danger present in the message DKIM-signing organization, and the potential danger present in the
stream signed by that organization. While it might seem that higher message stream signed by that organization. While it might seem that
trust automatically means lower risk, the experience with real-world higher trust automatically means lower risk, the experience with
operations provides examples of every combination of the two factors, real-world operations provides examples of every combination of the
as shown in Table 1. Only three levels of granularity are listed, in two factors, as shown in Figure 2. For each axis, only three levels
order to keep discussion manageable. This also ensures extensive of granularity are listed, in order to keep discussion manageable.
flexibility for each site's detailed choices. In real-world filtering engines, finer-grained distinctions are
typically needed, and there typically are more axes. For example,
there are different types of risk, so that an engine might
distinguish between spam risk versus virus risk and take different
actions based on which type of problematic content is present. For
spam, the potential damage from a false negative is small, whereas
the damage from a false positive is high. For a virus, the potential
danger from a false negative is extremely high, while the likelihood
of a false positive when using modern detection tools is extremely
low. However for the discussion here, "risk" is taken as a single
construct.
+-------------+-----------------+-----------------+-----------------+ The DKIM d= identifier is independent of any other identifier in a
| ORG TRUST \ | Low | Medium | High | message and can be a sub-domain of the name owned by the signer.
| MSG RISK | | | | This permits use of fine-grained and stable distinctions between
+-------------+-----------------+-----------------+-----------------+ different types of message streams, such as between transactional
| *Low* | Unknown org, | Registered org, | Good Org, Good | messages and marketing messages from the same organization. Hence,
| | Few msgs: _Mild | New Identifier: | msgs: _Avoid | use of DKIM might permit a richer filtering model than has typically
| | filter_ | _Medium filter_ | ;FP(!)_ | been possible for mail receiving engines.
| *Medium* | Unknown org, | Registered org, | Good org, Bad |
| | New Identifier: | Mixed msgs: | msg burst: |
| | _Default | _Medium filter_ | _Accept & |
| | filter_ | | Contact_ |
| *High* | Black-Listed | Registered org, | Good org, |
| | org, Bad msgs: | Bad msgs: | Compromised: |
| | _Avoid FN(!)_ | _Strong filter_ | _Fully blocked_ |
+-------------+-----------------+-----------------+-----------------+
Table 1: Org Trust vs. Msg Risk Note that the realities of today's public Internet Mail environment
necessitate having a baseline handling model that is quite
suspicious. Hence, "strong" filtering rules really are the starting
point, as indicated for the UNKNOWN cell.
The table indicates preferences for different handling of different The table indicates differential handling for each combination, such
combinations, such as tuning filtering to avoid False Positives (FP) as how aggressive or broad-based the filtering could be.
or avoiding False Negatives (FN). IT distinguishes various Aggressiveness affects the types of incorrect assessments that are
characteristics, including: 1) organizations that are unknown, known likely. So the table distinguishes various characteristics,
to be good actors and known to be bad actors; and 2) assessment of including: 1) whether an organization is unknown, known to be good
messages. It includes advice about the degree of filtering that actors and known to be bad actors; and 2) the assessment of messages.
might be done, and other message disposition. Perhaps unexpectedly, It includes advice about the degree of filtering that might be done,
it also lists a case in which the receiving site might wish to and other message disposition. Perhaps unexpectedly, it also lists a
deliver problematic mail, rather than redirecting it, but also of case in which the receiving site might wish to deliver problematic
course contacting the signing organization, seeking resolution of the mail, rather than redirecting or deleting it, but also contacting the
problem. signing organization and seeking
+-------------+-----------------------------------------------+
| S T R E A M * O R G A N I Z A T I O N A L T R U S T |
| R I S K * Low Medium High |
| +***************+***************+***************+
| Low * BENIGN: | DILIGENT: | PRISTINE |
| * Moderate | Mild | Accept |
| * filter | filter | |
| +---------------+---------------+---------------+
| Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
| * Strong | Targeted | Accept & |
| * filter | filter | Contact |
| +---------------+---------------+---------------+
| High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
| * Block & | Block | Block & |
| * Counter | | Contact |
+-------------+---------------+---------------+---------------+
Figure 2: Trust vs. Risk Handling Tradeoffs Example
[LEGEND]
AXES
Stream Risk: This is a measure of the recent history of a
message stream and the severity of problems it has presented.
Organizational Trust: This combines longer-term history about
possible stream problems from that organization, and its
responsiveness to problem handling.
CELLS (indicating reasonable responses)
Labels for the cells are meant as a general assessment of an
organization producing that type of mail stream under that
circumstance.
Benign: There is some history of sending good messages, with
very few harmful messages having been received. This stream
warrants filtering that does not search for problems very
aggressively, in order to reduce the likelihood of False
Positives.
Diligent: The stream has had a limited degree of problems and
the Organization is consistently successful at controlling
their abuse issues and in a timely manner.
Pristine: There is a history of a clean message stream with no
problems, from an Organization with an excellent reputation.
So, the filter primarily needs to ensure that messages are
delivered; catching stray problem messages is a lesser concern.
In other words, the paramount concern, here, is False
Positives.
-----
Unknown: There is no history with the Organization. Apply an
aggressive level of "naive" filtering, given the nature of the
public email environment.
Typical: The stream suffers significant abuse issues and the
Organization has demonstrated a record of having difficulties
resolving them in a timely manner, in spite of legitimate
efforts. Unfortunately, this is the typical case for service
providers with an easy and open subscription policy.
Protected: An Organization with a good history and/or providing
an important message stream for the receiving site is subject
to a local policy that messages are not allowed to be blocked,
but the stream is producing a problematic stream. The receiver
delivers messages, but works quickly with the Organization to
resolve the matter.
-----
Malicious: A persistently problematic message stream is coming
from an Organization that appears to contribute to the problem.
The stream will be blocked, but the Organization's role is
sufficiently troubling to warrant following up with others in
the anti-abuse or legal communities, to constrain or end their
impact.
Negligent: A persistently problematic message stream is coming
from an Organization that does not appear to be contributing to
the problem, but also does not appear to be working to
eliminate it. At the least, the stream needs to be blocked.
Compromised: An Organization with a good history has a stream
that changes and becomes too problematic to be delivered. The
receiver blocks the stream and works quickly with the
Organization to resolve the matter.
3. DKIM Key Generation, Storage, and Management 3. DKIM Key Generation, Storage, and Management
By itself, verification of a digital signature only allows the By itself, verification of a digital signature only allows the
verifier to conclude with a very high degree of certainty that the verifier to conclude with a very high degree of certainty that the
signature was created by a party with access to the corresponding signature was created by a party with access to the corresponding
private signing key. It follows that a verifier requires means to private signing key. It follows that a verifier requires means to
(1) obtain the public key for the purpose of verification and (2) (1) obtain the public key for the purpose of verification and (2)
infer useful attributes of the key holder. infer useful attributes of the key holder.
 End of changes. 16 change blocks. 
100 lines changed or deleted 198 lines changed or added

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