draft-ietf-dkim-deployment-08.txt   draft-ietf-dkim-deployment-09.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: February 26, 2010 Expires: April 29, 2010
P. Hallam-Baker P. Hallam-Baker
Default Deny Security, Inc. Default Deny Security, Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
August 25, 2009 October 26, 2009
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-08 draft-ietf-dkim-deployment-09
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 26, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 4, line 10 skipping to change at page 4, line 10
8.1. Non-standard Submission and Delivery Scenarios . . . . . . 35 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 35
8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 36 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 36
8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 36 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 36
8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 37 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 37
8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39
9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40
9.1. Security Considerations . . . . . . . . . . . . . . . . . 40 9.1. Security Considerations . . . . . . . . . . . . . . . . . 40
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11. Informative References . . . . . . . . . . . . . . . . . . . . 40 11. Informative References . . . . . . . . . . . . . . . . . . . . 40
Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 42 Appendix A. Migration Strategies . . . . . . . . . . . . . . . . 41
A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 42 A.1. Migrating from DomainKeys . . . . . . . . . . . . . . . . 41
A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 47 A.2. Migrating Hash Algorithms . . . . . . . . . . . . . . . . 46
A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 48 A.3. Migrating Signing Algorithms . . . . . . . . . . . . . . . 47
Appendix B. General Coding Criteria for Cryptographic Appendix B. General Coding Criteria for Cryptographic
Applications . . . . . . . . . . . . . . . . . . . . 48 Applications . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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; and those who are list software, and migrating from DomainKeys; and those who are
responsible for the on-going operations of an email infrastructure responsible for the on-going operations of an email infrastructure
that has deployed DKIM. that has deployed DKIM.
The document is organized around the key concepts related to DKIM. The document is organized around the key concepts related to DKIM.
Within each section, additional considerations specific to Within each section, additional considerations specific to
development, deployment, or ongoing operations are highlighted where development, deployment, or ongoing operations are highlighted where
appropriate. The possibility of use of DKIM results as input to a appropriate. The possibility of use of DKIM results as input to a
local reputation database is also discussed. local reputation database is also discussed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, except that
all uses are to be considered advisory rather than normative.
2. Using DKIM as Part of Trust Assessment 2. Using DKIM as Part of Trust Assessment
2.1. A Systems View of Email Trust Assessment 2.1. A Systems View of Email Trust Assessment
DKIM participates in a trust-oriented enhancement to the Internet's DKIM participates in a trust-oriented enhancement to the Internet's
email service, to facilitate message handling decisions, such as for email service, to facilitate message handling decisions, such as for
delivery and for content display. Trust-oriented message handling delivery and for content display. Trust-oriented message handling
has substantial differences from approaches that consider messages in has substantial differences from approaches that consider messages in
terms of risk and abuse. With trust, there is a collaborative terms of risk and abuse. With trust, there is a collaborative
exchange between a willing participant along the sending path and a exchange between a willing participant along the sending path and a
skipping to change at page 6, line 23 skipping to change at page 6, line 28
from determining that the content of a message is valid. The former from determining that the content of a message is valid. The former
means only that the identifier for the responsible role, person or means only that the identifier for the responsible role, person or
organization has been legitimately associated with a message. The organization has been legitimately associated with a message. The
latter means that the content of the message can be believed and, latter means that the content of the message can be believed and,
typically, that the claimed author of the content is correct. DKIM typically, that the claimed author of the content is correct. DKIM
validates only the presence of the identifier used to sign the validates only the presence of the identifier used to sign the
message. Even when this identifier is validated, DKIM carries no message. Even when this identifier is validated, DKIM carries no
implication that any of the message content, including the implication that any of the message content, including the
RFC5322.From field, is valid. Surprisingly, this limit to the RFC5322.From field, is valid. Surprisingly, this limit to the
semantics of a DKIM signature applies even when the validated signing semantics of a DKIM signature applies even when the validated signing
identifier is the same domain name as is used in the From: field! identifier is the same domain name as is used in the RFC5322.From
DKIM's only claim about message content is that the content cited in field! DKIM's only claim about message content is that the content
the DKIM-Signature: field's h= tag has been delivered without cited in the DKIM-Signature: field's h= tag has been delivered
modification. That is, it asserts message content integrity, not without modification. That is, it asserts message content integrity,
message content validity. not message content validity.
As shown in Figure 1, this enhancement is a communication between a As shown in Figure 1, this enhancement is a communication between a
responsible role, person or organization that signs the message and a responsible role, person or organization that signs the message and a
recipient organization that assesses its trust in the signer and then recipient organization that assesses its trust in the signer and then
makes handling decisions based on a collection of assessments, of makes handling decisions based on a collection of assessments, of
which the DKIM mechanism is only a part. In this model, validation which the DKIM mechanism is only a part. In this model, validation
is an intermediary step, having the sole task of passing a validated is an intermediary step, having the sole task of passing a validated
Responsible Identifier to the Identity Assessor. The communication Responsible Identifier to the Identity Assessor. The communication
is of a single Responsible Identifier that the Responsible Identity is of a single Responsible Identifier that the Responsible Identity
wishes to have used by the Identity Assessor. The Identifier is the wishes to have used by the Identity Assessor. The Identifier is the
skipping to change at page 7, line 50 skipping to change at page 8, line 7
used. DKIM has three values that specify identification information used. DKIM has three values that specify identification information
and it is easy to confuse their use, although only one defines the and it is easy to confuse their use, although only one defines the
formal input and output of DKIM, with the other two being used for formal input and output of DKIM, with the other two being used for
internal protocol functioning and adjunct purposes, such as auditing internal protocol functioning and adjunct purposes, such as auditing
and debugging. and debugging.
The salient values include the s=, d= and i= parameters in the DKIM- The salient values include the s=, d= and i= parameters in the DKIM-
Signature: header field. In order to achieve the end-to-end Signature: header field. In order to achieve the end-to-end
determinism needed for this collaborative exchange from the signer to determinism needed for this collaborative exchange from the signer to
the assessor, the core model needs to specify what the signer is the assessor, the core model needs to specify what the signer is
required to provide to the assessor. The Update to RFC4871 required to provide to the assessor. The Update to RFC4871 [RFC5672]
[I-D.ietf-dkim-rfc4871-errata]now specifies: now specifies:
DKIM's primary task is to communicate from the Signer to a DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single Signing Domain recipient-side Identity Assessor a single Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible Agent or User Identifier optionally provide a single responsible Agent or User Identifier
(AUID)... A receive-side DKIM verifier MUST communicate the (AUID)... A receive-side DKIM verifier MUST communicate the
Signing Domain Identifier (d=) to a consuming Identity Assessor Signing Domain Identifier (d=) to a consuming Identity Assessor
module and MAY communicate the User Agent Identifier (i=) if module and MAY communicate the User Agent Identifier (i=) if
present.... To the extent that a receiver attempts to intuit any present.... To the extent that a receiver attempts to intuit any
structured semantics for either of the identifiers, this is a structured semantics for either of the identifiers, this is a
skipping to change at page 10, line 25 skipping to change at page 10, line 30
stable pattern of traffic for developing an accurate and reliable stable pattern of traffic for developing an accurate and reliable
assessment. So the differentiation needs to achieve a balance. assessment. So the differentiation needs to achieve a balance.
Generally in a trust system, legitimate signers have an incentive to Generally in a trust system, legitimate signers have an incentive to
pick a small stable set of identities, so that recipients and others pick a small stable set of identities, so that recipients and others
can attribute reputations to them. The set of these identities a can attribute reputations to them. The set of these identities a
receiver trusts is likely to be quite a bit smaller than the set it receiver trusts is likely to be quite a bit smaller than the set it
views as risky. views as risky.
The challenge in using additional layers of sub-domains is whether The challenge in using additional layers of sub-domains is whether
the extra granularity will be useful for the assessor. In fact, the extra granularity will be useful for the assessor. In fact,
potentially excessive levels invites ambiguity: if the assessor does potentially excessive levels invite ambiguity: if the assessor does
not take advantage of the added granularity, then what granularity not take advantage of the added granularity, then what granularity
will it use? That ambiguity would move the use of DKIM back to the will it use? That ambiguity would move the use of DKIM back to the
realm of heuristics, rather than the deterministic processing that is realm of heuristics, rather than the deterministic processing that is
its goal. its goal.
Hence the challenge is to determine a useful scheme for labeling Hence the challenge is to determine a useful scheme for labeling
different traffic streams. The most obvious choices are among different traffic streams. The most obvious choices are among
different types of content and/or different types of authors. different types of content and/or different types of authors.
Although stability is essential, it is likely that the choices will Although stability is essential, it is likely that the choices will
change, over time, so the scheme needs to be flexible. change, over time, so the scheme needs to be flexible.
skipping to change at page 12, line 23 skipping to change at page 12, line 27
Absent such norms, it is best for signers to distinguish among Absent such norms, it is best for signers to distinguish among
streams that have significant differences, while consuming the streams that have significant differences, while consuming the
smallest number of identifiers possible. This will limit the smallest number of identifiers possible. This will limit the
burden on recipient Assessors. burden on recipient Assessors.
A common view about a DKIM signature is that it carries a degree of A common view about a DKIM signature is that it carries a degree of
assurance about some or all of the message contents, and in assurance about some or all of the message contents, and in
particular that the RFC5322.From field is likely to be valid. In particular that the RFC5322.From field is likely to be valid. In
fact, DKIM makes assurances only about the integrity of the data and fact, DKIM makes assurances only about the integrity of the data and
not about its validity. Still, presumptions of From: field validity not about its validity. Still, presumptions of RFC5322.From field
remain a concern. Hence a signer using a domain name that is validity remain a concern. Hence a signer using a domain name that
unrelated to the domain name in the From: field can reasonably expect is unrelated to the domain name in the RFC5322.From field can
that the disparity will warrant some curiosity, at least until reasonably expect that the disparity will warrant some curiosity, at
signing by independent operators has produced some established least until signing by independent operators has produced some
practice among recipient Assessors. established practice among recipient Assessors.
With the identifier(s) supplied by DKIM, the Assessor can consult an With the identifier(s) supplied by DKIM, the Assessor can consult an
independent assessment service about the entity associated with the independent assessment service about the entity associated with the
identifier(s). Another possibility is that the Assessor can develop identifier(s). Another possibility is that the Assessor can develop
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
skipping to change at page 15, line 25 skipping to change at page 15, line 28
While a DKIM signing key is used to sign messages on behalf of many While a DKIM signing key is used to sign messages on behalf of many
mail users, the signing key itself SHOULD be under direct control of mail users, the signing key itself SHOULD be under direct control of
as few key holders as possible. If a key holder were to leave the as few key holders as possible. If a key holder were to leave the
organization, all signing keys held by that key holder SHOULD be organization, all signing keys held by that key holder SHOULD be
withdrawn from service and if appropriate, replaced. withdrawn from service and if appropriate, replaced.
If key management hardware support is available, it SHOULD be used. If key management hardware support is available, it SHOULD be used.
If keys are stored in software, appropriate file control protections If keys are stored in software, appropriate file control protections
MUST be employed, and any location in which the private key is stored MUST be employed, and any location in which the private key is stored
in plaintext form SHOULD be excluded from regular backup processes in plaintext form SHOULD be excluded from regular backup processes
and SHOULD not be accessible through any form of network including and SHOULD NOT be accessible through any form of network including
private local area networks. Auditing software SHOULD be used private local area networks. Auditing software SHOULD be used
periodically to verify that the permissions on the private key files periodically to verify that the permissions on the private key files
remain secure. remain secure.
Wherever possible a signature key SHOULD exist in exactly one Wherever possible a signature key SHOULD exist in exactly one
location and be erased when no longer used. Ideally a signature key location and be erased when no longer used. Ideally a signature key
pair SHOULD be generated as close to the signing point as possible pair SHOULD be generated as close to the signing point as possible
and only the public key component transferred to another party. If and only the public key component transferred to another party. If
this is not possible, the private key MUST be transported in an this is not possible, the private key MUST be transported in an
encrypted format that protects the confidentiality of the signing encrypted format that protects the confidentiality of the signing
key. A shared directory on a local file system does not provide key. A shared directory on a local file system does not provide
adequate security for distribution of signing keys in plaintext form. adequate security for distribution of signing keys in plaintext form.
Key escrow schemes are not necessary and SHOULD NOT be used. In the Key escrow schemes are not necessary and SHOULD NOT be used. In the
unlikely event of a signing key becomming lost, a new signature key unlikely event of a signing key becoming lost, a new signature key
pair may be generated as easily as recovery from a key escrow scheme. pair may be generated as easily as recovery from a key escrow scheme.
To enable accountability and auditing: To enable accountability and auditing:
o Responsibility for the security of a signing key SHOULD ultimately o Responsibility for the security of a signing key SHOULD ultimately
vest in a single named individual. vest in a single named individual.
o Where multiple parties are authorized to sign messages, each o Where multiple parties are authorized to sign messages, each
signer SHOULD use a different key to enable accountability and signer SHOULD use a different key to enable accountability and
auditing. auditing.
skipping to change at page 16, line 27 skipping to change at page 16, line 28
In order to use DKIM a DNS domain holder requires (1) the ability to In order to use DKIM a DNS domain holder requires (1) the ability to
create the necessary DKIM DNS records and (2) sufficient operational create the necessary DKIM DNS records and (2) sufficient operational
security controls to prevent insertion of spurious DNS records by an security controls to prevent insertion of spurious DNS records by an
attacker. attacker.
DNS record management is often operated by an administrative staff DNS record management is often operated by an administrative staff
that is different from those who operate an organization's email that is different from those who operate an organization's email
service. In order to ensure that DKIM DNS records are accurate, this service. In order to ensure that DKIM DNS records are accurate, this
imposes a requirement for careful coordination between the two imposes a requirement for careful coordination between the two
operations groups. If the best practices for private key management operations groups. If the best practices for private key management
described above are observed, such deployment is not a one time described above are observed, such deployment is not a onetime event;
event; DNS DKIM selectors will be changed over time signing keys are DNS DKIM selectors will be changed over time signing keys are
terminated and replaced. terminated and replaced.
At a minimum, a DNS server that handles queries for DKIM key records At a minimum, a DNS server that handles queries for DKIM key records
MUST allow the server administrators to add free-form TXT records. MUST allow the server administrators to add free-form TXT records.
It would be better if the the DKIM records could be entered using a It would be better if the DKIM records could be entered using a
structured form, supporting the DKIM-specific fields. structured form, supporting the DKIM-specific fields.
Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that
provides protection against record insertion attacks and zone provides protection against record insertion attacks and zone
enumeration. In the case that NSEC3 [RFC5155] records are employed enumeration. In the case that NSEC3 [RFC5155] records are employed
to prevent insertion attack, the OPT-OUT flag MUST be set clear. to prevent insertion attack, the OPT-OUT flag MUST be set clear.
3.2.1. Assignment of Selectors 3.2.1. Assignment of Selectors
Selectors are assigned according to the administrative needs of the Selectors are assigned according to the administrative needs of the
skipping to change at page 16, line 51 skipping to change at page 17, line 4
3.2.1. Assignment of Selectors 3.2.1. Assignment of Selectors
Selectors are assigned according to the administrative needs of the Selectors are assigned according to the administrative needs of the
signing domain, such as for rolling over to a new key or for signing domain, such as for rolling over to a new key or for
delegating of the right to authenticate a portion of the namespace to delegating of the right to authenticate a portion of the namespace to
a trusted third party. Examples include: a trusted third party. Examples include:
jun2005.eng._domainkey.example.com jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.com widget.promotion._domainkey.example.com
It is intended that assessments of DKIM identities be based on the It is intended that assessments of DKIM identities be based on the
domain name, and not include the selector. While past practice of a domain name, and not include the selector. While past practice of a
signer may permit a verifier to infer additional properties of signer may permit a verifier to infer additional properties of
particular messages from the structure DKIM key selector, unannounced particular messages from the structure DKIM key selector, unannounced
administrative changes such as a change of signing softeware may administrative changes such as a change of signing software may cause
cause such heuristics to fail at any time. such heuristics to fail at any time.
3.3. Per User Signing Key Management Issues 3.3. Per User Signing Key Management Issues
While a signer may establish business rules, such as issue of While a signer may establish business rules, such as issue of
individual signature keys for each end-user, DKIM makes no provision individual signature keys for each end-user, DKIM makes no provision
for communicating these to other parties. Out of band distribution for communicating these to other parties. Out of band distribution
of such business rules is outside the scope of DKIM. Consequently of such business rules is outside the scope of DKIM. Consequently
there is no means by which external parties may make use of such keys there is no means by which external parties may make use of such keys
to attribute messages with any greater granularity than a DNS domain. to attribute messages with any greater granularity than a DNS domain.
skipping to change at page 18, line 18 skipping to change at page 18, line 19
serves to protect the interests of both parties. The domain holder serves to protect the interests of both parties. The domain holder
minimizes its security risk and the Trusted Third Party Signer avoids minimizes its security risk and the Trusted Third Party Signer avoids
unnecessary liability. unnecessary liability.
In the most restrictive case a domain holder maintains full control In the most restrictive case a domain holder maintains full control
over the creation of key records and employs appropriate key record over the creation of key records and employs appropriate key record
restrictions to enforce restrictions on the messages for which the restrictions to enforce restrictions on the messages for which the
third party signer is able to sign. If such restrictions are third party signer is able to sign. If such restrictions are
impractical, the domain holder SHOULD delegate a DNS subzone for impractical, the domain holder SHOULD delegate a DNS subzone for
publishing key records to the third party signer. The domain holder publishing key records to the third party signer. The domain holder
SHOULD not allow a third party signer unrestricted access to its DNS SHOULD NOT allow a third party signer unrestricted access to its DNS
service for the purpose of publishing key records. service for the purpose of publishing key records.
3.5. Key Pair / Selector Lifecycle Management 3.5. Key Pair / Selector Lifecycle Management
Deployments SHOULD establish, document and observe processes for Deployments SHOULD establish, document and observe processes for
managing the entire lifecycle of a public key pair. managing the entire lifecycle of a public key pair.
3.5.1. Example Key Deployment Process 3.5.1. Example Key Deployment Process
When it is determined that a new key pair is required: When it is determined that a new key pair is required:
1. A Key Pair is generated by the signing device. 1. A Key Pair is generated by the signing device.
2. A proposed key selector record is generated and transmitted to 2. A proposed key selector record is generated and transmitted to
the DNS administration infrasrtructure. the DNS administration infrastructure.
3. The DNS administration infrastructure verifies the authenticity 3. The DNS administration infrastructure verifies the authenticity
of the key selector registration request. If accepted of the key selector registration request. If accepted
1. A key selector is assigned. 1. A key selector is assigned.
2. The corresponding key record published in the DNS. 2. The corresponding key record published in the DNS.
3. Wait for DNS updates to propagate (if necessary). 3. Wait for DNS updates to propagate (if necessary).
skipping to change at page 19, line 15 skipping to change at page 19, line 18
3.5.2. Example Key Termination Process 3.5.2. Example Key Termination Process
When it is determined that a private signature key is no longer When it is determined that a private signature key is no longer
required: required:
1. Signer stops using the private key for signature operations. 1. Signer stops using the private key for signature operations.
2. Signer deletes all records of the private key, including in- 2. Signer deletes all records of the private key, including in-
memory copies at the signing device. memory copies at the signing device.
3. Signer notifies the DNS administration infrasrtructure that the 3. Signer notifies the DNS administration infrastructure that the
signing key is withdrawn from service and that the corresponding signing key is withdrawn from service and that the corresponding
key records may be withdrawn from service at a specified future key records may be withdrawn from service at a specified future
date. date.
4. The DNS administration infrastructure verifies the authenticity 4. The DNS administration infrastructure verifies the authenticity
of the key selector termination request. If accepted, of the key selector termination request. If accepted,
1. The key selector is scheduled for deletion at a future time 1. The key selector is scheduled for deletion at a future time
determined by site policy. determined by site policy.
skipping to change at page 20, line 11 skipping to change at page 20, line 15
o A DNS Administrative interface that can create and maintain the o A DNS Administrative interface that can create and maintain the
relevant DNS names -- including names with underscores -- and relevant DNS names -- including names with underscores -- and
resource records (RR). resource records (RR).
o A trusted module, called the Signing Module, which is within the o A trusted module, called the Signing Module, which is within the
organization's outbound email handling service and which creates organization's outbound email handling service and which creates
and adds the DKIM-Signature: header field(s) to the message. and adds the DKIM-Signature: header field(s) to the message.
If the module creates more than one signature, there needs to be the If the module creates more than one signature, there needs to be the
appropriate means of telling it which one(s) to use. If a large appropriate means of telling it which one(s) to use. If a large
number of names is used for signing, it will help to have the number of names are used for signing, it will help to have the
administrative tool support a batch processing mode. administrative tool support a batch processing mode.
4.1. DNS Records 4.1. DNS Records
A receiver attempting to verify a DKIM signature obtains the public A receiver attempting to verify a DKIM signature obtains the public
key that is associated with the signature for that message. The key that is associated with the signature for that message. The
DKIM-Signature: header in the message contains the d= tag with the DKIM-Signature: header in the message contains the d= tag with the
basic domain name doing the signing and serving as output to the basic domain name doing the signing and serving as output to the
Identity Assessor, and the s= tag with the selector that is added to Identity Assessor, and the s= tag with the selector that is added to
the name, for finding the specific public key. Hence, the relevant the name, for finding the specific public key. Hence, the relevant
skipping to change at page 23, line 17 skipping to change at page 23, line 17
In practice these limitations have little or no impact on the field In practice these limitations have little or no impact on the field
of use for which DKIM is designed but may have a bearing if use is of use for which DKIM is designed but may have a bearing if use is
made of the DKIM message signature format or key retrieval mechanism made of the DKIM message signature format or key retrieval mechanism
in other specifications. in other specifications.
In particular the DKIM key retrieval mechanism is designed for ease In particular the DKIM key retrieval mechanism is designed for ease
of use and deployment rather than to provide a high assurance Public of use and deployment rather than to provide a high assurance Public
Key Infrastructure suitable for purposes that require robust non- Key Infrastructure suitable for purposes that require robust non-
repudiation such as establishing legally binding contracts. repudiation such as establishing legally binding contracts.
Developers seeking to extend DKIM beyond its design application Developers seeking to extend DKIM beyond its design application
SHOULD consider replacing or supplementing the DNS key retreival SHOULD consider replacing or supplementing the DNS key retrieval
mechanism with one that is designed to meet the intended purposes. mechanism with one that is designed to meet the intended purposes.
5.4. Inbound Mail Filtering 5.4. Inbound Mail Filtering
DKIM is frequently employed in a mail filtering strategy to avoid DKIM is frequently employed in a mail filtering strategy to avoid
performing content analysis on email originating from trusted performing content analysis on email originating from trusted
sources. Messages that carry a valid DKIM signature from a trusted sources. Messages that carry a valid DKIM signature from a trusted
source may be whitelisted, avoiding the need to perform computation source may be whitelisted, avoiding the need to perform computation
and hence energy intensive content analysis to determine the and hence energy intensive content analysis to determine the
disposition of the message. disposition of the message.
Mail sources may be determined to be trusted by means of previously Mail sources may be determined to be trusted by means of previously
observed behavior and/or reference to external reputation or observed behavior and/or reference to external reputation or
accreditation services. The precise means by which this is accreditation services. The precise means by which this is
acomplished is outside the scope of DKIM. accomplished is outside the scope of DKIM.
5.4.1. Non-Verifying Adaptive Spam Filtering Systems 5.4.1. Non-Verifying Adaptive Spam Filtering Systems
Adaptive (or learning) spam filtering mechanisms that are not capable Adaptive (or learning) spam filtering mechanisms that are not capable
of verifying DKIM signatures SHOULD at minimum be configured to of verifying DKIM signatures SHOULD at minimum be configured to
ignore DKIM header data entirely. ignore DKIM header data entirely.
5.5. Messages sent through Mailing Lists and other Intermediaries 5.5. Messages sent through Mailing Lists and other Intermediaries
Intermediaries such as mailing lists pose a particular challenge for Intermediaries such as mailing lists pose a particular challenge for
skipping to change at page 25, line 9 skipping to change at page 25, line 9
and use such information can be assured that it truly pertains to the and use such information can be assured that it truly pertains to the
identity in question. identity in question.
This section lays out a taxonomy of some of the different identities, This section lays out a taxonomy of some of the different identities,
or combinations of identities, that might usefully be represented by or combinations of identities, that might usefully be represented by
a DKIM signature. a DKIM signature.
6.1. Single Domain Signature 6.1. Single Domain Signature
Perhaps the simplest case is when an organization signs its own Perhaps the simplest case is when an organization signs its own
outbound email using its own domain in the SDID outbound email using its own domain in the SDID [RFC5672] of the
[I-D.ietf-dkim-rfc4871-errata] of the signature. For example, signature. For example, Company A would sign the outbound mail from
Company A would sign the outbound mail from its employees with its employees with d=companyA.example.
d=companyA.example.
In the most straightforward configuration, the addresses in the In the most straightforward configuration, the addresses in the
RFC5322.From would also be in the companyA.example domain, but that RFC5322.From would also be in the companyA.example domain, but that
direct correlation is not required. direct correlation is not required.
A special case of the Single Domain Signature is an Author Signature A special case of the Single Domain Signature is an Author Signature
as defined by the Author Domain Signing Practices specification as defined by the Author Domain Signing Practices specification
[RFC5617]. Author signatures are signatures from an author's [RFC5617]. Author signatures are signatures from an author's
organization that have an SDID value that matches that of an organization that have an SDID value that matches that of an
RFC5322.From address of the signed message. RFC5322.From address of the signed message.
skipping to change at page 26, line 17 skipping to change at page 26, line 15
Section 2.3, if the type of mail sent from the different subdomains Section 2.3, if the type of mail sent from the different subdomains
is significantly different or if there is reason to believe that the is significantly different or if there is reason to believe that the
reputation of the subdomains would differ, then it may be a good idea reputation of the subdomains would differ, then it may be a good idea
to acknowledge this and provide distinct signatures for each of the to acknowledge this and provide distinct signatures for each of the
subdomains (d=marketing.domain.example, sales.domain.example, etc.). subdomains (d=marketing.domain.example, sales.domain.example, etc.).
However, if the mail and reputations are likely to be similar, then However, if the mail and reputations are likely to be similar, then
the simpler approach of using a single common parent domain in the the simpler approach of using a single common parent domain in the
signature may work well. signature may work well.
Another approach to distinguishing the streams using a single DKIM Another approach to distinguishing the streams using a single DKIM
key would be to leverage the AUID [I-D.ietf-dkim-rfc4871-errata] (i= key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM
tag) in the DKIM signature to differentiate the mail streams. For signature to differentiate the mail streams. For example, marketing
example, marketing email would be signed with email would be signed with i=marketing.domain.example and
i=marketing.domain.example and d=domain.example. d=domain.example.
It's important to remember, however, that under core DKIM semantics It's important to remember, however, that under core DKIM semantics
the AUID is opaque to receivers. That means that it will only be an the AUID is opaque to receivers. That means that it will only be an
effective differentiator if there is an out of band agreement about effective differentiator if there is an out of band agreement about
the i= semantics. the i= semantics.
6.3. Third Party Signature 6.3. Third Party Signature
A signature whose domain does not match the domain of the A signature whose domain does not match the domain of the
RFC5322.From address is sometimes referred to as a third party RFC5322.From address is sometimes referred to as a third party
signature. In certain cases even the parent domain signature signature. In certain cases even the parent domain signature
described above would be considered a third party signature because described above would be considered a third party signature because
it would not be an exact match for the domain in the From: address. it would not be an exact match for the domain in the RFC5322.From
address.
Although there is often heated debate about the value of third party Although there is often heated debate about the value of third party
signatures, it is important to note that the DKIM specification signatures, it is important to note that the DKIM specification
attaches no particular significance to the identity in a DKIM attaches no particular significance to the identity in a DKIM
signature. The identity specified within the signature is the signature. The identity specified within the signature is the
identity that is taking responsibility for the message, and it is identity that is taking responsibility for the message, and it is
only the interpretation of a given receiver that gives one identity only the interpretation of a given receiver that gives one identity
more or less significance than another. In particular, most more or less significance than another. In particular, most
independent reputation services assign trust based on the specific independent reputation services assign trust based on the specific
identifier string, not its "role": in general they make no identifier string, not its "role": in general they make no
distinction between, for example, an author signature and a third distinction between, for example, an author signature and a third
party signature. party signature.
For some, a signature unrelated to the author domain (the domain in For some, a signature unrelated to the author domain (the domain in
the RFC5322.From address) is less valuable because there is an the RFC5322.From address) is less valuable because there is an
assumption that the presence of an author signature guarantees that assumption that the presence of an author signature guarantees that
the use of the address in the From: header is authorized. the use of the address in the RFC5322.From header is authorized.
For others, that relevance is tied strictly to the recorded For others, that relevance is tied strictly to the recorded
behavioral data assigned to the identity in question, i.e. its trust behavioral data assigned to the identity in question, i.e. its trust
assessment or reputation. The reasoning here is that an identity assessment or reputation. The reasoning here is that an identity
with a good reputation is unlikely to maintain that good reputation with a good reputation is unlikely to maintain that good reputation
if it is in the habit of vouching for messages that are unwanted or if it is in the habit of vouching for messages that are unwanted or
abusive; in fact, doing so will rapidly degrade its reputation so abusive; in fact, doing so will rapidly degrade its reputation so
that future messages will no longer benefit from it. It is therefore that future messages will no longer benefit from it. It is therefore
low risk to facilitate the delivery of messages that contain a valid low risk to facilitate the delivery of messages that contain a valid
signature of a domain with a strong positive reputation, independent signature of a domain with a strong positive reputation, independent
skipping to change at page 29, line 17 skipping to change at page 29, line 17
Companies with multiple subdomain identities: A company that has Companies with multiple subdomain identities: A company that has
multiple subdomains sending distinct categories of mail might multiple subdomains sending distinct categories of mail might
choose to sign with distinct subdomain identities to enable each choose to sign with distinct subdomain identities to enable each
subdomain to manage its own identity. However, it might also want subdomain to manage its own identity. However, it might also want
to provide a common identity that cuts across all of the distinct to provide a common identity that cuts across all of the distinct
subdomains. For example, Company A may sign mail for its sales subdomains. For example, Company A may sign mail for its sales
department with a signature where d=sales.companya.example, and a department with a signature where d=sales.companya.example, and a
second signature where d=companya.example second signature where d=companya.example
Service Providers: A service providers may, as described above, Service Providers: Service providers may, as described above, choose
choose to sign outbound messages with either its own identity or to sign outbound messages with either its own identity or with an
with an identity unique to each of its clients (possibly identity unique to each of its clients (possibly delegated).
delegated). However, it may also do both: sign each outbound However, it may also do both: sign each outbound message with its
message with its own identity as well as with the identity of each own identity as well as with the identity of each individual
individual client. For example, ESP A might sign mail for its client. For example, ESP A might sign mail for its client Company
client Company B with its service provider signature B with its service provider signature d=espa.example, and a second
d=espa.example, and a second client-specific signature where d= client-specific signature where d= either companyb.example, or
either companyb.example, or companyb.espa.example. The existence companyb.espa.example. The existence of the service provider
of the service provider signature could, for example, help cover a signature could, for example, help cover a new client while it
new client while it establishes its own reputation, or help a very establishes its own reputation, or help a very small volume client
small volume client who might never reach a volume threshold who might never reach a volume threshold sufficient to establish
sufficient to establish an individual reputation. an individual reputation.
Forwarders Forwarded mail poses a number of challenges to email Forwarders Forwarded mail poses a number of challenges to email
authentication. DKIM is relatively robust in the presence of authentication. DKIM is relatively robust in the presence of
forwarders as long as the signature is designed to avoid message forwarders as long as the signature is designed to avoid message
parts that are likely to be modified; however, some forwarders do parts that are likely to be modified; however, some forwarders do
make modifications that can invalidate a DKIM signature. make modifications that can invalidate a DKIM signature.
Some forwarders such as mailing lists or "forward article to a Some forwarders such as mailing lists or "forward article to a
friend" services might choose to add their own signatures to friend" services might choose to add their own signatures to
outbound messages to vouch for them having legitimately originated outbound messages to vouch for them having legitimately originated
skipping to change at page 29, line 51 skipping to change at page 29, line 51
added even in the presence of a preexisting signature, and both added even in the presence of a preexisting signature, and both
signatures would be relevant to the verifier. signatures would be relevant to the verifier.
Any forwarder that modifies messages in ways that will break Any forwarder that modifies messages in ways that will break
preexisting DKIM signatures SHOULD always sign its forwarded preexisting DKIM signatures SHOULD always sign its forwarded
messages. messages.
Reputation Providers: Although third party reputation providers Reputation Providers: Although third party reputation providers
today use a variety of protocols to communicate their information today use a variety of protocols to communicate their information
to receivers, it is possible that they, or other organizations to receivers, it is possible that they, or other organizations
willing to put their "seal of approval" on an email stream might willing to put their "seal of approval" on an email stream, might
choose to use a DKIM signature to do it. In nearly all cases, choose to use a DKIM signature to do it. In nearly all cases,
this "reputation" signature would be in addition to the author or this "reputation" signature would be in addition to the author or
originator signature. originator signature.
One important caveat to the use of multiple signatures is that there One important caveat to the use of multiple signatures is that there
is currently no clear consensus among receivers on how they plan to is currently no clear consensus among receivers on how they plan to
handle them. The opinions range from ignoring all but one signature handle them. The opinions range from ignoring all but one signature
(and the specification of which of them is verified differs from (and the specification of which of them is verified differs from
receiver to receiver), to verifying all signatures present and receiver to receiver), to verifying all signatures present and
applying a weighted blend of the trust assessments for those applying a weighted blend of the trust assessments for those
skipping to change at page 30, line 34 skipping to change at page 30, line 34
evaluated under the same reputation or a different one, and so on. evaluated under the same reputation or a different one, and so on.
This section provides some examples of usage scenarios for DKIM This section provides some examples of usage scenarios for DKIM
deployments; the selection is not intended to be exhaustive, but to deployments; the selection is not intended to be exhaustive, but to
illustrate a set of key deployment considerations. illustrate a set of key deployment considerations.
7.1. Author's Organization - Simple 7.1. Author's Organization - Simple
The simplest DKIM configuration is to have some mail from a given The simplest DKIM configuration is to have some mail from a given
organization (Company A) be signed with the same d= value (e.g. organization (Company A) be signed with the same d= value (e.g.
d=companya.example). If there is a desire to associate additional d=companya.example). If there is a desire to associate additional
information, the AUID [I-D.ietf-dkim-rfc4871-errata] value can become information, the AUID [RFC5672] value can become
uniqueID@companya.example, or @uniqueID.companya.example. uniqueID@companya.example, or @uniqueID.companya.example.
In this scenario, Company A need only generate a single signing key In this scenario, Company A need only generate a single signing key
and publish it under their top level domain (companya.example); the and publish it under their top level domain (companya.example); the
signing module would then tailor the AUID value as needed at signing signing module would then tailor the AUID value as needed at signing
time. time.
7.2. Author's Organization - Differentiated Types of Mail 7.2. Author's Organization - Differentiated Types of Mail
A slight variation of the one signature case is where Company A signs A slight variation of the one signature case is where Company A signs
skipping to change at page 31, line 20 skipping to change at page 31, line 20
of the legitimate mail for a domain is signed, recipients can be more of the legitimate mail for a domain is signed, recipients can be more
aggressive in their filtering of mail that uses the domain but does aggressive in their filtering of mail that uses the domain but does
not have a valid signature from the domain; in such a configuration, not have a valid signature from the domain; in such a configuration,
the absence of a signature would be more significant than for the the absence of a signature would be more significant than for the
general case. It might be desirable for such domains to be able to general case. It might be desirable for such domains to be able to
advertise their intent to other receivers: this is the topic of advertise their intent to other receivers: this is the topic of
Author Domain Signing Practices (ADSP). Author Domain Signing Practices (ADSP).
Note that ADSP is not for everyone. Sending domains that do not Note that ADSP is not for everyone. Sending domains that do not
control all legitimate outbound mail purporting to be from their control all legitimate outbound mail purporting to be from their
domain (i.e., with a RFC5322.From address in their domain) are likely domain (i.e., with an RFC5322.From address in their domain) are
to experience delivery problems with some percentage of that mail. likely to experience delivery problems with some percentage of that
Administrators evaluating ADSP for their domains SHOULD carefully mail. Administrators evaluating ADSP for their domains SHOULD
weigh the risk of phishing attacks against the likelihood of carefully weigh the risk of phishing attacks against the likelihood
undelivered mail. of undelivered mail.
This section covers some examples of ADSP usage: for the complete This section covers some examples of ADSP usage: for the complete
specification, see [RFC5617] specification, see [RFC5617]
7.3.2. A Few Definitions 7.3.2. A Few Definitions
In the ADSP specification, an address in the From header field of a In the ADSP specification, an address in the RFC5322.From header
message [RFC5322] is defined as an "Author Address", and an "Author field of a message is defined as an "Author Address", and an "Author
Domain" is defined as anything to the right of the '@' in an Author Domain" is defined as anything to the right of the '@' in an Author
Address. Address.
An "Author Signature" is thus any valid signature where the value of An "Author Signature" is thus any valid signature where the value of
the SDID matches an Author Domain in the message. the SDID matches an Author Domain in the message.
It is important to note that unlike the DKIM specification which It is important to note that unlike the DKIM specification which
makes no correlation between the signature domain and any message makes no correlation between the signature domain and any message
headers, the ADSP specification applies only to the author domain. headers, the ADSP specification applies only to the author domain.
In essence, under ADSP, any non-author signatures are ignored In essence, under ADSP, any non-author signatures are ignored
skipping to change at page 32, line 20 skipping to change at page 32, line 20
validating ADSP, Company A MUST first have done an exhaustive validating ADSP, Company A MUST first have done an exhaustive
analysis to determine all sources of outbound mail from its domain analysis to determine all sources of outbound mail from its domain
(companyA.example) and ensure that they all have valid author (companyA.example) and ensure that they all have valid author
signatures from that domain. signatures from that domain.
For example, email with an RFC5322.From address of bob@ For example, email with an RFC5322.From address of bob@
companyA.example MUST have an author signature where the SDID value companyA.example MUST have an author signature where the SDID value
is "companyA.example" or it will fail an ADSP validation. is "companyA.example" or it will fail an ADSP validation.
Note that once an organization publishes an ADSP record using Note that once an organization publishes an ADSP record using
dkim=all or dkim=discardable, any email with a RFC5322.From address dkim=all or dkim=discardable, any email with an RFC5322.From address
that uses the domain where the ADSP record is published that does not that uses the domain where the ADSP record is published that does not
have a valid author signature is at risk of being misdelivered or have a valid author signature is at risk of being misdelivered or
discarded. For example, if a message with an RFC5322.From address of discarded. For example, if a message with an RFC5322.From address of
newsletter@companyA.example has a signature with newsletter@companyA.example has a signature with
d=marketing.companyA.example, that message will fail the ADSP check d=marketing.companyA.example, that message will fail the ADSP check
because the signature would not be considered a valid author because the signature would not be considered a valid author
signature. signature.
Because the semantics of an ADSP author signature are more Because the semantics of an ADSP author signature are more
constrained than the semantics of a "pure" DKIM signature, it is constrained than the semantics of a "pure" DKIM signature, it is
skipping to change at page 33, line 16 skipping to change at page 33, line 16
through the benefits providers email servers shares the Company A through the benefits providers email servers shares the Company A
reputation, as discussed in Section 6.4 it can either publish keys reputation, as discussed in Section 6.4 it can either publish keys
designated for the use of the benefits provider under designated for the use of the benefits provider under
companyA.example (preferably under a designated subdomain of companyA.example (preferably under a designated subdomain of
companyA.example), or it can delegate a subdomain (e.g. companyA.example), or it can delegate a subdomain (e.g.
benefits.companyA.example) to the provider and enable the provider to benefits.companyA.example) to the provider and enable the provider to
generate the keys and manage the DNS for the designated subdomain. generate the keys and manage the DNS for the designated subdomain.
In both of these cases, mail would be physically going out of the In both of these cases, mail would be physically going out of the
benefit provider's mail servers with a signature of e.g. benefit provider's mail servers with a signature of e.g.
d=benefits.companya.example. Note that the From: address is not d=benefits.companya.example. Note that the RFC5322.From address is
constrained: it could either be affiliated with the benefits company not constrained: it could either be affiliated with the benefits
(e.g. benefits-admin@benefitprovider.example, or company (e.g. benefits-admin@benefitprovider.example, or
benefits-provider@benefits.companya.example), or with the companyA benefits-provider@benefits.companya.example), or with the companyA
domain. domain.
Note that in both of the above scenarios, as discussed in Note that in both of the above scenarios, as discussed in
Section 3.4, security concerns dictate that the keys be generated by Section 3.4, security concerns dictate that the keys be generated by
the organization that plans to do the signing so that there is no the organization that plans to do the signing so that there is no
need to transfer the private key. In other words, the benefits need to transfer the private key. In other words, the benefits
provider would generate keys for both of the above scenarios. provider would generate keys for both of the above scenarios.
7.5. Independent Third Party Service Providers 7.5. Independent Third Party Service Providers
skipping to change at page 35, line 21 skipping to change at page 35, line 21
private key. This has the side effect that email submission and private key. This has the side effect that email submission and
delivery scenarios that originate or relay messages from outside the delivery scenarios that originate or relay messages from outside the
domain of the authorized signing module will not have access to that domain of the authorized signing module will not have access to that
protected private key, and thus will be unable to attach the expected protected private key, and thus will be unable to attach the expected
domain signature to those messages. Such scenarios include mailing domain signature to those messages. Such scenarios include mailing
lists, courtesy forwarders, MTAs at hotels, hotspot networks used by lists, courtesy forwarders, MTAs at hotels, hotspot networks used by
travelling users, and other paths that could add or modify headers, travelling users, and other paths that could add or modify headers,
or modify the message body. or modify the message body.
For example, assume Joe works for Company A and has an email address For example, assume Joe works for Company A and has an email address
joe@companya.example. Joe also has a ISP-1 account joe@companya.example. Joe also has an ISP-1 account
joe@isp1.example.com, and he uses ISP-1's multiple address feature to joe@isp1.example.com, and he uses ISP-1's multiple address feature to
attach his work email joe@companya.example to his ISP-1 account. attach his work email joe@companya.example to his ISP-1 account.
When Joe sends email from his ISP-1 account and uses When Joe sends email from his ISP-1 account and uses
joe@companya.example as his designated From: address, that email joe@companya.example as his designated RFC5322.From address, that
cannot have a signature with d=companya.example because the ISP-1 email cannot have a signature with d=companya.example because the
servers have no access to Company A's private key. In ISP-1's case ISP-1 servers have no access to Company A's private key. In ISP-1's
it will have a ISP-1 signature, but for some other mail clients case it will have an ISP-1 signature, but for some other mail clients
offering the same multiple address feature there may be no signature offering the same multiple address feature there may be no signature
at all on the message. at all on the message.
Another example might be the use of a forward article to a friend Another example might be the use of a forward article to a friend
service. Most instances of these services today allow someone to service. Most instances of these services today allow someone to
send an article with their email address in the RFC5322.From to their send an article with their email address in the RFC5322.From to their
designated recipient. If Joe used either of his two addresses designated recipient. If Joe used either of his two addresses
(joe@companya.example or joe@isp1.example.com), the forwarder would (joe@companya.example or joe@isp1.example.com), the forwarder would
be equally unable to sign with a corresponding domain . As in the be equally unable to sign with a corresponding domain. As in the
mail client case, the forwarder may either sign as its own domain, or mail client case, the forwarder may either sign as its own domain, or
may put no signature on the message. may put no signature on the message.
A third example is the use of privately configured forwarding. A third example is the use of privately configured forwarding.
Assume that Joe has another account at ISP-2, joe@isp-2.example.com, Assume that Joe has another account at ISP-2, joe@isp-2.example.com,
but he'd prefer to read his ISP-2 mail from his ISP-1 account. He but he'd prefer to read his ISP-2 mail from his ISP-1 account. He
sets up his ISP-2 account to forward all incoming mail to sets up his ISP-2 account to forward all incoming mail to
joe@isp1.example.com. Assume alice@companyb.example sends joe@isp1.example.com. Assume alice@companyb.example sends
joe@isp-2.example.com an email. Depending on how companyb.example joe@isp-2.example.com an email. Depending on how companyb.example
configured its signature, and depending on whether or not ISP-2 configured its signature, and depending on whether or not ISP-2
skipping to change at page 36, line 51 skipping to change at page 36, line 51
The primary way to sign with per-user keys requires each user to have The primary way to sign with per-user keys requires each user to have
a distinct DNS (sub)domain, where each distinct d= value has a key a distinct DNS (sub)domain, where each distinct d= value has a key
published. (It is possible, although not recommended, to publish the published. (It is possible, although not recommended, to publish the
same key in more than one distinct domain.) same key in more than one distinct domain.)
It is technically possible to publish per-user keys within a single It is technically possible to publish per-user keys within a single
domain or subdomain by utilizing different selector values. This is domain or subdomain by utilizing different selector values. This is
not recommended and is unlikely to be treated uniquely by Assessors: not recommended and is unlikely to be treated uniquely by Assessors:
the primary purpose of selectors is to facilitate key management, and the primary purpose of selectors is to facilitate key management, and
the DKIM specification recommends against using them in determining the DKIM specification recommends against using them in determining
or assessing identies. or assessing identities.
In most cases, it would be impractical to sign email on a per-user In most cases, it would be impractical to sign email on a per-user
granularity. Such an approach would be granularity. Such an approach would be
likely to be ignored: In most cases today, if receivers are likely to be ignored: In most cases today, if receivers are
verifying DKIM signatures they are in general taking the simplest verifying DKIM signatures they are in general taking the simplest
possible approach. In many cases maintaining reputation possible approach. In many cases maintaining reputation
information at a per user granularity is not interesting to them, information at a per-user granularity is not interesting to them,
in large part because the per user volume is too small to be in large part because the per-user volume is too small to be
useful or interesting. So even if senders take on the complexity useful or interesting. So even if senders take on the complexity
necessary to support per user signatures, receivers are unlikely necessary to support per-user signatures, receivers are unlikely
to retain anything more than the base domain reputation. to retain anything more than the base domain reputation.
difficult to manage: Any scheme that involves maintenance of a difficult to manage: Any scheme that involves maintenance of a
significant number of public keys may require infrastructure significant number of public keys may require infrastructure
enhancements or extensive administrative expertise. For domains enhancements or extensive administrative expertise. For domains
of any size, maintaining a valid per-user keypair, knowing when of any size, maintaining a valid per-user keypair, knowing when
keys need to be revoked or added due to user attrition or keys need to be revoked or added due to user attrition or
onboarding, and the overhead of having the signing engine onboarding, and the overhead of having the signing engine
constantly swapping keys can create significant and often constantly swapping keys can create significant and often
unnecessary managment complexity. It is also important to note unnecessary management complexity. It is also important to note
that there is no way within the scope of the DKIM specification that there is no way within the scope of the DKIM specification
for a receiver to infer that a sender intends a per-user for a receiver to infer that a sender intends a per-user
granularity. granularity.
As mentioned before, what may make sense, however, is to use the As mentioned before, what may make sense, however, is to use the
infrastructure that enables finer granularity in signatures to infrastructure that enables finer granularity in signatures to
identify segments smaller than a domain but much larger than a per- identify segments smaller than a domain but much larger than a per-
user segmentation. For example, a university might want to segment user segmentation. For example, a university might want to segment
student, staff, and faculty mail into three distinct streams with student, staff, and faculty mail into three distinct streams with
differing reputations. This can be done by creating seperate sub- differing reputations. This can be done by creating separate sub-
domains for the desired segments, and either specifying the domains for the desired segments, and either specifying the
subdomains in the i= tag of the DKIM Signature or by adding subdomains in the i= tag of the DKIM Signature or by adding
subdomains to the d= tag and assigning and signing with different subdomains to the d= tag and assigning and signing with different
keys for each subdomain. keys for each subdomain.
For those who choose to represent user level granularity in For those who choose to represent user level granularity in
signatures, the performance and management considerations above signatures, the performance and management considerations above
suggest that it would be more effective to do it by specifying a suggest that it would be more effective to do it by specifying a
local part or subdomain extension in the i= tag rather than by local part or subdomain extension in the i= tag rather than by
extending the d= domain and publishing individual keys. extending the d= domain and publishing individual keys.
skipping to change at page 39, line 23 skipping to change at page 39, line 23
specific to those venues. In particular, MUAs MAY also support DKIM specific to those venues. In particular, MUAs MAY also support DKIM
signing and verifying directly. signing and verifying directly.
Outbound: An MUA MAY support signing even if mail is to be Outbound: An MUA MAY support signing even if mail is to be
relayed through an outbound MSA. In this case the signature relayed through an outbound MSA. In this case the signature
applied by the MUA will be in addition to any signature added applied by the MUA will be in addition to any signature added
by the MSA. However, the warnings in the previous section by the MSA. However, the warnings in the previous section
should be taken into consideration. should be taken into consideration.
Some user software goes beyond simple user functionality and Some user software goes beyond simple user functionality and
also perform MSA and MTA functions. When this is employed for also performs MSA and MTA functions. When this is employed for
sending directly to a receiving ADMD, the user software SHOULD sending directly to a receiving ADMD, the user software SHOULD
be considered an outbound MTA. be considered an outbound MTA.
Inbound: An MUA MAY rely on a report of a DKIM signature Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA/ verification that took place at some point in the inbound MTA/
MDA path (e.g., an Authentication-Results header field), or an MDA path (e.g., an Authentication-Results header field), or an
MUA MAY perform DKIM signature verification directly. A MUA MAY perform DKIM signature verification directly. A
verifying MUA SHOULD allow for the case where mail has modified verifying MUA SHOULD allow for the case where mail has modified
in the inbound MTA path; if a signature fails, the message in the inbound MTA path; if a signature fails, the message
SHOULD NOT be treated any different than if it did not have a SHOULD NOT be treated any different than if it did not have a
skipping to change at page 39, line 48 skipping to change at page 39, line 48
considered trustable. The MUA developer is encouraged to re- considered trustable. The MUA developer is encouraged to re-
read the Security Considerations of [RFC5451]. read the Security Considerations of [RFC5451].
DKIM requires that all verifiers treat messages with signatures DKIM requires that all verifiers treat messages with signatures
that do not verify as if they are unsigned. that do not verify as if they are unsigned.
If verification in the client is to be acceptable to users, it If verification in the client is to be acceptable to users, it
is essential that successful verification of a signature not is essential that successful verification of a signature not
result in a less than satisfactory user experience compared to result in a less than satisfactory user experience compared to
leaving the message unsigned. The mere presence of a verified leaving the message unsigned. The mere presence of a verified
DKIM signature MUST NOT by itself be used by an MUA to indicate DKIM signature MUST NOT be used by itself by an MUA to indicate
that a message is to be treated better than a message without a that a message is to be treated better than a message without a
verified DKIM signature. However, the fact that a DKIM verified DKIM signature. However, the fact that a DKIM
signature was verified MAY be used as input into a reputation signature was verified MAY be used as input into a reputation
system (i.e., a whitelist of domains and users) for system (i.e., a whitelist of domains and users) for
presentation of such indicators. presentation of such indicators.
It is common for components of an ADMD's email infrastructure to do It is common for components of an ADMD's email infrastructure to do
violence to a message, such that a DKIM signature might be rendered violence to a message, such that a DKIM signature might be rendered
invalid. Hence, users of MUAs that support DKIM signing and/or invalid. Hence, users of MUAs that support DKIM signing and/or
verifying need a basis for knowing that their associated email verifying need a basis for knowing that their associated email
skipping to change at page 40, line 31 skipping to change at page 40, line 31
9.2. IANA Considerations 9.2. IANA Considerations
This document has no considerations for IANA. This document has no considerations for IANA.
10. Acknowledgements 10. Acknowledgements
TBD TBD
11. Informative References 11. Informative References
[I-D.ietf-dkim-rfc4871-errata]
Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
Signatures -- Update", draft-ietf-dkim-rfc4871-errata-07
(work in progress), June 2009.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
Object Security Services", RFC 1848, October 1995.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
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.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating [RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009. Message Authentication Status", RFC 5451, April 2009.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, Identified Mail (DKIM) Service Overview", RFC 5585,
July 2009. July 2009.
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,
"DomainKeys Identified Mail (DKIM) Author Domain Signing "DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)", RFC 5617, August 2009. Practices (ADSP)", RFC 5617, August 2009.
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
Signatures -- Update", RFC 5672, August 2009.
Appendix A. Migration Strategies Appendix A. Migration Strategies
There are three migration occassions worth noting in particular for There are three migration occassions worth noting in particular for
DKIM: DKIM:
1. Migrating from Domain Keys to DKIM. 1. Migrating from Domain Keys to DKIM.
2. Migrating from a current hash algorithm to a new standardized 2. Migrating from a current hash algorithm to a new standardized
hash algorithm. hash algorithm.
 End of changes. 51 change blocks. 
136 lines changed or deleted 105 lines changed or added

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