draft-ietf-dkim-overview-03.txt   draft-ietf-dkim-overview-04.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational D. Crocker Intended status: Informational D. Crocker
Expires: April 26, 2007 Brandenburg InternetWorking Expires: September 5, 2007 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
October 23, 2006 March 4, 2007
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Message Signing Service Overview
draft-ietf-dkim-overview-03 draft-ietf-dkim-overview-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on September 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) associates a "responsible" identity
with a message and provides a means of verifying that the association with a message and provides a means of verifying that the association
is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level
authentication framework for email using public-key cryptography and authentication framework for email using public-key cryptography and
key server technology. This permits verifying the source or key server technology. This permits verifying the source or
intermediary for a message, as well as the contents of messages. The intermediary for a message, as well as the contents of messages. The
ultimate goal of this framework is to permit a signing domain to ultimate goal of this framework is to permit a signing domain to
assert responsibility for a message, thus proving and protecting the assert responsibility for a message, thus proving and protecting the
identity associated with the message and the integrity of the identity associated with the message and the integrity of the
messages itself, while retaining the functionality of Internet email messages itself, while retaining the functionality of Internet email
as it is known today. Such protection of email identity, may assist as it is known today. Such protection of email identity, may assist
in the global control of "spam" and "phishing". This document in the global control of "spam" and "phishing". This document
provides an overview of DKIM and describes how it can fit into a provides an overview of DKIM and describes how it can fit into a
messaging service, how it relates to other IETF message signature messaging service, how it relates to other IETF message signature
technologies. It also includes implementation and migration technologies. It also includes implementation and migration
considerations. considerations.
Note
This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DKIM's Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. The DKIM Value Proposition . . . . . . . . . . . . . . . . 5
3.1. Treat verification failure as if unsigned. . . . . . . . 8 1.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Domain-level assurance . . . . . . . . . . . . . . . . . 8 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Incremental adoption . . . . . . . . . . . . . . . . . . 8 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Minimal infrastructure . . . . . . . . . . . . . . . . . 9 2.1. Treat verification failure as if unsigned. . . . . . . . . 7
3.5. Transparent signature . . . . . . . . . . . . . . . . . . 9 2.2. Domain-level assurance . . . . . . . . . . . . . . . . . . 7
3.6. Security policy . . . . . . . . . . . . . . . . . . . . . 9 2.3. Incremental adoption . . . . . . . . . . . . . . . . . . . 7
4. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . . . 9 2.4. Minimal infrastructure . . . . . . . . . . . . . . . . . . 8
4.1. What is a DKIM signature? . . . . . . . . . . . . . . . . 10 2.5. Transparent signature . . . . . . . . . . . . . . . . . . 8
4.2. The Selector construct . . . . . . . . . . . . . . . . . 10 2.6. Security policy . . . . . . . . . . . . . . . . . . . . . 9
4.3. Who validates the signature? . . . . . . . . . . . . . . 10 3. Function and Use . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. What does DKIM NOT do? . . . . . . . . . . . . . . . . . 11 3.1. What is a DKIM signature? . . . . . . . . . . . . . . . . 9
4.5. Does DKIM eliminate anonymity for email? . . . . . . . . 11 3.2. The Selector construct . . . . . . . . . . . . . . . . . . 9
4.6. Outline potential DKIM applications . . . . . . . . . . . 11 3.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. What is a DKIM policy? . . . . . . . . . . . . . . . . . 11 3.4. What does DKIM NOT do? . . . . . . . . . . . . . . . . . . 10
5. DKIM Within Existing Internet Email . . . . . . . . . . . . . 12 3.5. Does DKIM eliminate anonymity for email? . . . . . . . . . 11
5.1. Review of Internet Mail Service Architecture . . . . . . 12 4. DKIM Within Existing Internet Email . . . . . . . . . . . . . 11
5.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 15 4.1. Review of Internet Mail Service Architecture . . . . . . . 11
5.3. Impact on Email Activities . . . . . . . . . . . . . . . 16 4.2. Where to Place DKIM Functions . . . . . . . . . . . . . . 14
5.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 18 4.3. Impact on Email Activities . . . . . . . . . . . . . . . . 15
6. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 19 4.4. Migrating from DomainKeys . . . . . . . . . . . . . . . . 17
7. Implementation Considerations . . . . . . . . . . . . . . . . 21 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 18
7.1. Development . . . . . . . . . . . . . . . . . . . . . . . 21 6. Development . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Coding Criteria for Cryptographic Applications . . . . . . 20
7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Email Infrastructure Agents . . . . . . . . . . . . . . . 21
7.4. Accreditation service . . . . . . . . . . . . . . . . . . 24 6.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Transition strategy . . . . . . . . . . . . . . . . . . . 27 7.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 25
9.1. DNS Signature Record Deployment Considerations . . . . . 28 7.4. Transition strategy . . . . . . . . . . . . . . . . . . . 25
9.2. Private Key Management . . . . . . . . . . . . . . . . . 30 8. On-going Operations . . . . . . . . . . . . . . . . . . . . . 27
9.3. Mailing List Management . . . . . . . . . . . . . . . . . 31 8.1. DNS Signature Record Deployment Considerations . . . . . . 27
10. Outline Future Extensions . . . . . . . . . . . . . . . . . . 31 8.2. Private Key Management . . . . . . . . . . . . . . . . . . 29
10.1. Introducing a new signing algorithm . . . . . . . . . . . 32 8.3. Mailing list manager developers . . . . . . . . . . . . . 29
10.2. Possible future signature algorithm choices . . . . . . . 33 9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.3. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33 9.1. Protection of Internal Mail . . . . . . . . . . . . . . . 30
10.4. Trusted Third Party Assertions . . . . . . . . . . . . . 34 9.2. Recipient-based Assessments . . . . . . . . . . . . . . . 30
10.5. Linkage to X.509 Certificates . . . . . . . . . . . . . . 35 9.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 31
10.6. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.4. Per user signature . . . . . . . . . . . . . . . . . . . . 31
10.7. Verification in the Client . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10.8. Per user signature . . . . . . . . . . . . . . . . . . . 36 11. { Misc Text -- Should go elsewhere, if used at all } . . . . . 32
10.9. Encryption . . . . . . . . . . . . . . . . . . . . . . . 37 12. Informative References . . . . . . . . . . . . . . . . . . . . 33
10.10. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
10.11. Use of Policy Record . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
12. { Misc Text -- Should go elsewhere, if used at all } . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. References -- Normative . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) associates a "responsible" identity
with a message and provides a means of verifying that the association
is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level
authentication framework for email using public-key cryptography and
key server technology. This permits verifying the source or
intermediary for a message, as well as the contents of messages. The
ultimate goal of this framework is to permit a signing domain to
assert responsibility for a message, thus proving and protecting the
identity associated with the message and the integrity of the
messages itself, while retaining the functionality of Internet email
as it is known today. Such protection of email identity, may assist
in the global control of "spam" and "phishing". This document
provides an overview of DKIM and describes how it can fit into a
messaging service, how it relates to other IETF message signature
technologies. It also includes implementation and migration
considerations.
This document provides an overview of DomainKeys Identified Mail This document provides an overview of DomainKeys Identified Mail
(DKIM). It is intended for those who are adopting, developing, or (DKIM). It is intended for those who are adopting, developing, or
deploying DKIM. It also will be helpful for those who are deploying DKIM. It also will be helpful for those who are
considering extending DKIM, either into other areas or to support considering extending DKIM, either into other areas or to support
additional features. This Overview does not provide information on additional features. This Overview does not provide information on
threats to DKIM or email, or details on the protocol specifics, which threats to DKIM or email, or details on the protocol specifics, which
can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats], can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats],
respectively. The document assumes a background in basic network respectively. The document assumes a background in basic network
security technology and services. security technology and services.
NOTE: It must be stressed that neither this document nor DKIM It must be stressed that neither this document nor DKIM attempt to
attempt to provide solutions to the world's problems with spam, provide solutions to the world's problems with spam, phish, virii,
phish, virii, worms, joe jobs, etc. DKIM creates one, basic tool worms, joe jobs, etc. DKIM creates one basic tool in what needs to
in what needs to be a large arsenal of tools, for improving the be a large arsenal of tools, for improving the safety of Internet
safety of Internet mail. However by itself, DKIM is not mail. However by itself, DKIM is not sufficient to that task and
sufficient to that task and this Overview does not pursue the this Overview does not pursue the issues of integrating DKIM into
issues of integrating DKIM into these larger efforts. Rather, it these larger efforts. Rather, it is a basic introduction to the
is a basic introduction to the technology and its deployment. technology and its deployment.
NOTE: A number of sections in this document are just placeholders, 1.1. Background
for now.
There have been four other efforts at standardizing an email There have been four other efforts at standardizing an email
signature scheme: signature scheme:
o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989] o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989]
and eventually transformed into MIME Object Security Services in
1995 [RFC1848]. Today, they are only of historical interest. o PEM eventually transformed into MIME Object Security Services in
1995 [RFC1848]. Today, these two are only of historical interest.
o Pretty Good Privacy (PGP) was developed by Phil Zimmerman and o Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
first released in 1991.[RFC1991] A later version was standardized first released in 1991.[RFC1991] A later version was standardized
as OpenPGP. [RFC3156] as OpenPGP. [RFC3156]
o RSA Security, the holder of the patent rights to the principle o RSA Security, the holder of the patent rights to the principle
public key cryptography algorithm, independently developed Secure public key cryptography algorithm, independently developed Secure
MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851] MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851]
Development of S/MIME and OpenPGP has continued. While both have Development of S/MIME and OpenPGP has continued. While both have
achieved a significant user base neither has achieved ubiquity in achieved a significant user base, neither has achieved ubiquity in
deployment or use and their goals differ from those of DKIM. deployment or use and their goals differ from those of DKIM.
In principle the S/MIME protocol can support semantics such as domain In principle the S/MIME protocol can support semantics such as domain
level signatures or make use of keys stored in the DNS. However the level signatures or make use of keys stored in the DNS. However the
currently deployed base does not and modifying it to do so would currently deployed base does not and modifying it to do so would
require extensive effort. require extensive effort.
Unlike all four previous IETF email security initiatives, DKIM Unlike previous IETF email security initiatives, DKIM employs a key
employs a key centric Public Key Infrastructure (PKI) as opposed to centric Public Key Infrastructure (PKI) as opposed to one that is
one that is based on a certificate in the style of Kohnfelder (X.509) based on a certificate in the style of Kohnfelder (X.509) or
or Zimmerman (web of trust). That is, the owner of a key asserts its Zimmerman (web of trust). That is, the owner of a key asserts its
validity, rather than relying on having a broader semantic validity, rather than relying on having a broader semantic
implication of the assertion, such as a quality assessment of the implication of the assertion, such as a quality assessment of the
key's owner. DKIM treats quality assessment as an independent, key's owner. DKIM treats quality assessment as an independent,
value-added service, beyond the initial work of deploying a value-added service, beyond the initial work of deploying a
validating signature service. validating signature service.
NOTE: It would be useful to include a citation to a general
discussion about PKI issues, including their long history of
difficulties with respect to the Internet.
Further, DKIM's PKI is supported as additional information records to Further, DKIM's PKI is supported as additional information records to
the existing Domain Name Service, rather than requiring deployment of the existing Domain Name Service, rather than requiring deployment of
a new query infrastructure. This approach also has significant a new query infrastructure. This approach also has significant
performance advantages as DNS is layered on UDP and key retrieval is performance advantages as DNS is layered on UDP and key retrieval is
typically achieved in a single round trip. typically achieved in a single round trip.
2. The DKIM Value Proposition 1.2. The DKIM Value Proposition
Spam can be understood as two separate problems. The first is the Spam can be understood as two separate problems. The first is the
problem of the companies that are inappropriately aggressive, in problem of companies that are inappropriately aggressive, in sending
sending out unsolicited marketing email. This accounts for, perhaps, out unsolicited marketing email. This accounts for, perhaps, 5% of
5% of the spam volume and is in any case usually handled by existing the spam volume and is in any case usually handled by existing spam
spam filters. The second problem is rogue spam -- often involving filters. [N.B. need a reference for the 5%.] The second problem is
criminal activities -- mostly sent from coerced botnets of rogue spam -- often involving criminal activities -- mostly sent from
compromised machines. For this latter set of mail, the origins of a coerced botnets of compromised machines. For this latter set of
message are often falsely stated. mail, the origins of a message are often falsely stated.
Even without the addition of independent accreditation services, DKIM DKIM provides a means of associating a verifiable identity with a
allows pair-wise sets of (possibly large) email providers and spam message. Given the presence of that identity, a receiver can make
filtering companies to distinguish mail that is associated with a decisions about further handling of the message, based upon
known organization, from mail that might deceptively purport to have assessments of that identity.
the affiliation. This in turn allows the development of 'whitelist'
schemes whereby authenticated mail from a known source with good
reputation is allowed to bypass some spam filters.
In effect the email receiver is using their set of known For messages that produce a valid signature, it will be possible to
relationships to generate their own accreditation/reputation data. make affirmative trust assessments. For messages using identities
This works particularly well for traffic between large sending that are typically signed, it will be possible to detect some types
providers and large receiving providers. However it also works well of phishing emails and block them.
for any operator, public or private, that has mail traffic dominated
by exchanges among a stable set of organizations.
NOTE: Perhaps add some citations to detailed discussions about spam 1.3. Phishing
and phishing and the role of authentication and accreditation in
fighting them?
DKIM used in conjunction with a real-time blacklist allows phishing The value of a cousin domain, that could be mistaken for the
emails to be preemptively blocked. The value of a cousin domain, legitimate domain, is significantly reduced if the number of emails
that could be mistaken for the legitimate domain, is significantly that can be successfully sent from it is small.
reduced if the number of emails that can be successfully sent from it
is small.
Phishing attacks are typically made against trusted brands, that is, Phishing attacks are typically made against trusted brands, that is,
names that are closely affiliated with well-known organizations. A names that are closely affiliated with well-known organizations. A
DKIM-based accreditation service can enforce a basic separation DKIM-based accreditation service can enforce a basic separation
between domains used by such known organizations and domains used by between domains used by such known organizations and domains used by
others. others.
Receivers who successfully validate a signature can use information Receivers who successfully validate a signature can use information
about the signer as part of a program to limit spam, spoofing, about the signer as part of a program to limit spam, spoofing,
phishing, or other undesirable behavior, although the DKIM phishing, or other undesirable behavior, although the DKIM
specification itself does not prescribe any specific actions by the specification itself does not prescribe any specific actions by the
recipient. recipient.
3. DKIM's Goals 1.4. Conventions
In this document, references to structured fields of a message use a
two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name
of the field. Hence <RFC2822.From> is the From field in an email
content header [RFC2822] and <RFC2821.MailFrom> is the address in the
SMTP "Mail From" command. [RFC2821]
This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org.
2. Goals
DKIM lets an organization take responsibility for a message. The DKIM lets an organization take responsibility for a message. The
organization taking responsibility typically is a handler of the organization taking responsibility typically is a handler of the
message, either as its originator or as an intermediary. It can also message, either as its originator or as an intermediary. It can also
be an independent service, providing assistance to a handler of the be an independent service, providing assistance to a handler of the
message. Their reputation is the basis for evaluating whether to message. Their reputation is the basis for evaluating whether to
trust the message for delivery. trust the message for delivery.
The owner of the domain name being used for a DKIM signature is The owner of the domain name being used for a DKIM signature is
declaring that they are accountable for the message. This means that declaring that they are accountable for the message. This means that
skipping to change at page 7, line 50 skipping to change at page 7, line 15
By design, DKIM purposely: By design, DKIM purposely:
o is compatible with the existing email infrastructure and o is compatible with the existing email infrastructure and
transparent to the fullest extent possible transparent to the fullest extent possible
o requires minimal new infrastructure o requires minimal new infrastructure
o can be implemented independently of clients in order to reduce o can be implemented independently of clients in order to reduce
deployment time deployment time
o does not require the use of trusted third parties (e.g., o does not require the use of new trusted third parties (e.g.,
certificate authorities) that might impose significant costs or certificate authorities) that might impose significant costs or
introduce delays to deployment introduce delays to deployment
o can be deployed incrementally, with separate deployment of signers o can be deployed incrementally, with separate deployment of signers
and verifiers in either order and verifiers in either order
o allows delegation of signing to third parties o allows delegation of signing to third parties
o is not intended be used for archival purposes o is not intended be used for archival purposes
DKIM authentication provides one link in a chain of responsibility, DKIM authentication provides one link in a chain of responsibility,
hopefully leading to better accountability by the senders. hopefully leading to better accountability by the senders.
3.1. Treat verification failure as if unsigned. 2.1. Treat verification failure as if unsigned.
PGP and S/MIME were both designed for strong cryptographic PGP and S/MIME were both designed for strong cryptographic
protection. This included treating validation failure as message protection. This included treating validation failure as message
failure, at least warning the user that the message was unsigned. In failure. For DKIM, the guidance is that an email signature verifier
a small number of cases the application went even further by is to treat messages with signatures that fail as if they were
'warning' the user whenever a signed message was received. This unsigned. Hence the message will revert to normal handling, through
approach has proved problematic. Hence for DKIM, the guidance is the receiver's existing filtering mechanisms.
that an email signature verifier is to treat messages with signatures
that fail as if they were unsigned.
It is highly unlikely that an attacker is going to add a digital
signature to a message unless doing so causes the message to be
treated more favorably than an unsigned one. Any messages that carry
signatures that fail verification are thus much more likely to be a
genuine message that has been damaged in transit than an attempted
forgery. It makes no sense to warn the recipient unless it is known
that the sender always signs email messages and that there is a high
probability that a forgery would be attempted.
3.2. Domain-level assurance 2.2. Domain-level assurance
PGP and S/MIME apply the end-to-end principle in terms of individual PGP and S/MIME apply the end-to-end principle in terms of individual
originators and recipients, notably using full email addresses. DKIM originators and recipients, notably using full email addresses. DKIM
seeks accountability at the more coarse grain of an organization or, seeks accountability at the more coarse grain of an organization or,
perhaps, a department. A deployed construct that enables this perhaps, a department. A deployed construct that enables this
granularity is the domain name, to which the signing key record is granularity is the domain name, to which the signing key record is
bound. bound.
3.3. Incremental adoption 2.3. Incremental adoption
DKIM can immediately provide benefits between any two organizations DKIM can immediately provide benefits between any two organizations
that exchange email and implement DKIM. In the usual manner of that exchange email and implement DKIM. In the usual manner of
"network effects", the benefits of DKIM increase dramatically as its "network effects", the benefits of DKIM increase dramatically as its
adoption increases. adoption increases.
Although it is envisioned that this mechanism will call upon
independent assessment services, they are not essential in order to
obtain initial benefit. For example DKIM allows pair-wise sets of
(possibly large) email providers and spam filtering companies to
distinguish mail that is associated with a known organization, from
mail that might deceptively purport to have the affiliation. This in
turn allows the development of 'whitelist' schemes whereby
authenticated mail from a known source with good reputation is
allowed to bypass some spam filters. In effect the email receiver is
using their set of known relationships to generate their own
accreditation/reputation data. This works particularly well for
traffic between large sending providers and large receiving
providers. However it also works well for any operator, public or
private, that has mail traffic dominated by exchanges among a stable
set of organizations.
Over time, DKIM adoption might become sufficiently widespread to Over time, DKIM adoption might become sufficiently widespread to
permit special, negative handling of messages that are not signed. permit special, negative handling of messages that are not signed.
However early benefits do not require this more-stringent However early benefits do not require this more-stringent
enforcement. enforcement.
3.4. Minimal infrastructure 2.4. Minimal infrastructure
DKIM can be implemented at a variety of places within an DKIM can be implemented at a variety of places within an
organization's email service. This permits the organization to organization's email service. This permits the organization to
choose how much or how little they want DKIM to be part of their choose how much or how little they want DKIM to be part of their
infrastructure, rather than part of a more localized operation. infrastructure, rather than part of a more localized operation.
Similarly, DKIM's reliance on the Domain Name Service greatly reduces Similarly, DKIM's reliance on the Domain Name Service greatly reduces
the amount of new administrative infrastructure that must be deployed the amount of new administrative infrastructure that must be deployed
over the open Internet. over the open Internet.
Even with use of the DNS, one challenge is that it is usually Even with use of the DNS, one challenge is that it is usually
operated by different administrative staff than those who operate an operated by different administrative staff than those who operate an
organization's email service. In order to ensure that DKIM DNS organization's email service. In order to ensure that DKIM DNS
records are accurate, this imposes a requirement for careful records are accurate, this imposes a requirement for careful
coordination between the two operations groups. coordination between the two operations groups.
3.5. Transparent signature 2.5. Transparent signature
S/MIME and PGP both modify the message body. Hence, their presence S/MIME and PGP both modify the message body. Hence, their presence
is visible to all email recipients and their user software must be is visible to all email recipients and their user software must be
able to process the associated constructs. In order to facilitate able to process the associated constructs. In order to facilitate
incremental adoption, DKIM is designed to be transparent to incremental adoption, DKIM is designed to be transparent to
recipients that do not support it. recipients that do not support it.
3.6. Security policy 2.6. Security policy
DKIM is pursuing an incremental innovation, over basic identity DKIM separates basic authentication from policy. An authenticated
authentication, through the publication of security policies identity may be subject to a variety of processing policies, either
associated with one or of the identities presented in a message. For ad hoc or standardized. The only policy inherent in a DKIM signature
example, a valid DKIM signature allows the signing party to assert is that the signer is asserting (some) responsibility for the
responsibility for a message. For a recipient to interpret an message. Other possible policies to consider developing include
unsigned message it is necessary to know whether it should expect a asserting a relationship between the signing identity and the author
message from that source to be signed and if so the signature (RFC 2822 From) domain identity, as well as whether to tread unsigned
characteristics to expect. It would, therefore, be helpful for a message with that From domain as problematic. It would, therefore,
potential signer to be able to publish whether they sign all of their be helpful for a potential signer to be able to publish various
message. Once this is published, recipients can choose to handle the policies, to permit a receiver to know more about the signer's
receipt of unsigned messages with added caution. practices
4. A Quick Overview of DKIM 3. Function and Use
DKIM has a very constrained set of capabilities, primarily targeting DKIM has a very constrained set of capabilities, primarily targeting
email while it is in transit, from an originator to one or more email while it is in transit, from an originator to one or more
recipients. DKIM defines a mechanism by which email messages can be recipients. DKIM defines a mechanism by which email messages can be
cryptographically signed, permitting a signing domain to claim cryptographically signed, permitting a signing domain to claim
responsibility for the presence of a message in the mail stream. A responsibility for the presence of a message in the mail stream. A
responsible organization adds a digital signature to the message, responsible organization adds a digital signature to the message,
associating it with a domain name of that organization. Typically, associating it with a domain name of that organization. Typically,
signing will be done by a service agent within the authority of the signing will be done by a service agent within the authority of the
message originator's Administrative Management Domain (ADMD). message originator's Administrative Management Domain (ADMD).
(Signing might be performed by any of the functional components in (Signing might be performed by any of the functional components in
that environment, including a Mail User Agent (MUA), a Mail that environment, including a Mail User Agent (MUA), a Mail
Submission Agent (MSA), or an Internet Boundary MTA. DKIM also Submission Agent (MSA), or an Internet Boundary MTA. DKIM also
permits signing to be performed by authorized third-parties.) permits signing to be performed by authorized third-parties.)
4.1. What is a DKIM signature? 3.1. What is a DKIM signature?
A signature covers the message body and selected header fields. The A signature covers the message body and selected header fields. The
signer computes a hash of the selected header fields and another hash signer computes a hash of the selected header fields and another hash
of the body. They then use a private key to cryptographically encode of the body. They then use a private key to cryptographically encode
this information, along with other signing parameters. The signature this information, along with other signing parameters. The signature
information is placed into a new header field of the RFC2822 information is placed into a new header field of the [RFC2822]
[RFC2822] message. message.
4.2. The Selector construct 3.2. The Selector construct
In order to allow a domain name to support multiple, simultaneous For a single domain, DKIM permits use of multiple signing keys and/or
keys, a particular signature is identified by the combination of the multiple signers. To do this, DKIM identifies a particular signature
domain name and an added field, called the "selector". Both of these as a combination of the domain name and an added field, called the
are coded into the DKIM-Signature header field. Selectors are "selector". Both of these are coded into the DKIM-Signature header
assigned according to the administrative needs of the signing domain, field.
such as for rolling over to a new key or for delegating of the right
to authenticate a portion of the namespace to a trusted third party. Selectors are assigned according to the administrative needs of the
signing domain, such as for rolling over to a new key or for
delegating of the right to authenticate a portion of the namespace to
a trusted third party.
Examples include: jun2005.eng._domainkey.example.com Examples include: jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.com widget.promotion._domainkey.example.com
NOTE: It is intended that assessments of DKIM identities be based NOTE: It is intended that assessments of DKIM identities be
on the domain name, and not include the selector. This permits based on the domain name, and not include the selector. This
the selector to be used only for key administration, rather than permits the selector to be used only for key administration,
having an effect on reputation assessment. rather than having an effect on reputation assessment.
4.3. Who validates the signature? 3.3. Validation
After a message has been signed, any agent in the message transit After a message has been signed, any agent in the message transit
path can choose to validate the signature. Validation of the path can choose to validate the signature, to determine that the
signature, by a later agent in the path, demonstrates that the signing identity took responsibility for the message. Message
signing identity took responsibility for the message recipients can verify the signature by querying the signer's domain
directly to retrieve the appropriate public key, and thereby confirm
Message recipients can verify the signature by querying the signer's that the message was attested to by a party in possession of the
domain directly to retrieve the appropriate public key, and thereby private key for the signing domain. Typically, validation will be
confirm that the message was attested to by a party in possession of done by an agent in the ADMD of the message recipient.
the private key for the signing domain. Typically, validation will
be done by an agent in the ADMD of the message recipient. Again,
this may be done by any functional component within that environment.
(Notably this means that the signature can be used by the recipient
ADMD's filtering software, rather than requiring the recipient end-
user to make an assessment.)
4.4. What does DKIM NOT do? 3.4. What does DKIM NOT do?
DKIM does not: A DKIM signature does not:
o offer any assertions about the behaviors of the identity doing the o offer any assertions about the behaviors of the identity doing the
signing. signing.
o prescribe any specific actions for receivers to take upon o prescribe any specific actions for receivers to take upon
successful (or unsuccessful) signature validation. successful (or unsuccessful) signature validation.
o provide protection after message delivery. o provide protection after message delivery.
o protect against re-sending (replay of) a message that already has o protect against re-sending (replay of) a message that already has
a valid signature; therefore a transit intermediary or a recipient a valid signature; therefore a transit intermediary or a recipient
can re-post the message in such a way that the signature would can re-post the message in such a way that the signature would
remain valid, although the new recipient(s) would not have been remain valid, although the new recipient(s) would not have been
specified by the originator. specified by the originator.
4.5. Does DKIM eliminate anonymity for email? 3.5. Does DKIM eliminate anonymity for email?
The ability to send a message that does not identify its author is The ability to send a message that does not identify its author is
considered to be a valuable quality of the current email system. It considered to be a valuable quality of the current email system. It
turns out that DKIM is particularly helpful to this goal, because a turns out that DKIM is particularly helpful to this goal, because a
DKIM signature will typically be used to identity an email system DKIM signature will typically be used to identity an email system
operator, rather than a content author. Knowing that a mail operator, rather than a content author. Knowing that a mail
definitely came from example.com does not threaten the anonymity of definitely came from example.com does not threaten the anonymity of
the user, if it is still possible to obtain effectively anonymous the user, if it is still possible to obtain effectively anonymous
accounts at example.com and other web mail providers. accounts at example.com and other web mail providers.
4.6. Outline potential DKIM applications 4. DKIM Within Existing Internet Email
TBD
4.7. What is a DKIM policy?
TBD
5. DKIM Within Existing Internet Email
5.1. Review of Internet Mail Service Architecture 4.1. Review of Internet Mail Service Architecture
Internet Mail has a simple split between the user world, in the form Internet Mail has a simple split between the user world, in the form
of Mail User Agents (MUA), and the transmission world, in the form of of Mail User Agents (MUA), and the transmission world, in the form of
the Mail Handling Service (MHS) composed of Mail Transfer Agents the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User (MTA). The MHS is responsible for accepting a message from one User
and delivering it to one or more other users, creating a virtual MUA- and delivering it to one or more other users, creating a virtual MUA-
to-MUA exchange environment. The first MTA is called the Mail to-MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and the final MTA is called the Mail Delivery Submission Agent (MSA) and the final MTA is called the Mail Delivery
Agent (MDA) Agent (MDA)
+--------+ +--------+
+---------------->| User | +---------------->| User |
| +--------+ | +--------+
| ^ | ^
+--------+ | +--------+ . +--------+ | +--------+ .
| User +--+--------->| User | . | User +--+--------->| User | .
+--------+ | +--------+ . +--------+ | +--------+ .
. | ^ . . | ^ .
. | +--------+ . . . | +--------+ . .
. +-->| User | . . . +-->| User | . .
skipping to change at page 13, line 5 skipping to change at page 12, line 37
+--------------------------------------+ +--------------------------------------+
Figure 1: Basic Internet Mail Service Model Figure 1: Basic Internet Mail Service Model
Modern Internet Mail service is marked by many independent operators, Modern Internet Mail service is marked by many independent operators,
many different components for providing users with service and many many different components for providing users with service and many
other components for performing message transfer. Consequently, it other components for performing message transfer. Consequently, it
is necessary to distinguish administrative boundaries that surround is necessary to distinguish administrative boundaries that surround
sets of functional components. sets of functional components.
5.1.1. Administrative Actors 4.1.1. Administrative Actors
Operation of Internet Mail services is apportioned to different Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). An ADMD operates with an ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust. Examples include an end- to differing types and amounts of trust. Examples include an end-
user operating their desktop client, a department operating a local user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured operating a public shared email service. These can be configured
into many combinations of administrative and operational into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with activities within the ADMD, versus those involving interactions with
other ADMDs. other ADMDs.
Basic components of ADMD distinction include: Basic components of ADMD distinction include:
Edge -- Independent transfer services, in networks at the edge Edge: Independent transfer services, in networks at the edge of
of the Internet Mail service. the Internet Mail service.
User -- End-user services. These might be subsumed under an User: End-user services. These might be subsumed under an Edge
Edge service, such as is common for web-based email access. service, such as is common for web-based email access.
Transit -- These are Mail Service Providers (MSP) offering Transit: These are Mail Service Providers (MSP) offering value-
value-added capabilities for Edge ADMDs, such as aggregation added capabilities for Edge ADMDs, such as aggregation and
and filtering. filtering.
Note that Transit services are quite different from packet-level Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level. is often directly between the Edge ADMDs, at the email level.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 | | ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- | | ----- | | ----- | | ----- |
| | +---------------------->| | | | | | +---------------------->| | | |
skipping to change at page 14, line 36 skipping to change at page 14, line 5
Figure 2: ADministrative Management Domains (ADMD) Example Figure 2: ADministrative Management Domains (ADMD) Example
The distinction between Transit network and Edge network transfer The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for services is primarily significant because it highlights the need for
concern over interaction and protection between independent concern over interaction and protection between independent
administrations. The interactions between functional components administrations. The interactions between functional components
within an ADMD are subject to the policies of that domain. within an ADMD are subject to the policies of that domain.
Common ADMD examples are: Common ADMD examples are:
Enterprise Service Providers -- Operating an organization's Enterprise Service Providers: Operating an organization's
internal data and/or mail services. internal data and/or mail services.
Internet Service Providers -- Operating underlying data Internet Service Providers: Operating underlying data
communication services that, in turn, are used by one or more communication services that, in turn, are used by one or more
Relays and Users. It is not necessarily their job to perform Relays and Users. It is not necessarily their job to perform
email functions, but they can, instead, provide an environment email functions, but they can, instead, provide an environment
in which those functions can be performed. in which those functions can be performed.
Mail Service Providers -- Operating email services, such as for Mail Service Providers: Operating email services, such as for
end-users, or mailing lists. end-users, or mailing lists.
5.1.2. Field Referencing Convention 4.2. Where to Place DKIM Functions
In this document, references to structured fields of a message use a
two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name
of the field. Hence <RFC2822.From> is the From field in an email
content header [RFC2822] and <RFC2821.MailFrom> is the address in the
SMTP "Mail From" command. [RFC2821]
5.2. Where to Place DKIM Functions
DKIM associates a "responsible" identity with a message and provides
a means of verifying that the association is legitimate. Deciding
which ADMD shall perform signing or verifying, which identity to
assign and which functional components to use for DKIM processing
depends upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it.
Deciding which ADMD shall perform signing or verifying, which
identity to assign and which functional components to use for DKIM
processing depends upon the nature of the trust/reputation that is of
interest and the most convenient or efficient way to use it.
Messages may be signed or verified by any functional component within Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange. Examples include: an ADMD, as that domain wishes to arrange. Examples include:
Outbound -- MUA, MSA or boundary MTA. Outbound: MUA, MSA or boundary MTA.
Inbound -- Boundary MTA, MDA or MUA. Inbound: Boundary MTA, MDA or MUA.
By having an MUA do the signing or verifying, there is no dependence By having an MUA do the signing or verifying, there is no dependence
upon implementation by an email service infrastructure. By having an upon implementation by an email service infrastructure. By having an
MHS component do signing or verifying, there is no dependence upon MHS component do signing or verifying, there is no dependence upon
user training or the upgrade of potentially large numbers of user user training or the upgrade of potentially large numbers of user
applications. applications.
For implementation by an ADMD's email service operators, perhaps the For implementation by an ADMD's email service operators, perhaps the
most obvious choices within the MHS are the MSA or MDA, and the most obvious choices within the MHS are the MSA or MDA, and the
outbound or inbound (boundary) MTA. By signing or verifying at the outbound or inbound (boundary) MTA. By signing or verifying at the
skipping to change at page 16, line 5 skipping to change at page 15, line 5
true end-to-end service, and requires the smallest amount of trust of true end-to-end service, and requires the smallest amount of trust of
the intervening service infrastructure. By signing or verifying at a the intervening service infrastructure. By signing or verifying at a
boundary, the smallest number of systems need modifying within an boundary, the smallest number of systems need modifying within an
ADMD and the signature is subject to the smallest amount of handling ADMD and the signature is subject to the smallest amount of handling
that can break the signature. Note, however, that this will that can break the signature. Note, however, that this will
eliminate DKIM signing for mail that stays within the ADMD. eliminate DKIM signing for mail that stays within the ADMD.
The choice of identity to use might not be obvious. Examples The choice of identity to use might not be obvious. Examples
include: include:
Author -- The domain associated with the RFC2822.From field Author: The domain associated with the RFC2822.From field
provides basic authorization for the author to generate mail. provides basic authorization for the author to generate mail.
Because the organization controlling that domain is closest to Because the organization controlling that domain is closest to
the author, they well might be in the best position to offer the author, they well might be in the best position to offer
their reputation as a basis for asserting that the content is their reputation as a basis for asserting that the content is
"safe". "safe".
Operator -- Email recipient services have long-used the IP Operator: Email recipient services have long-used the IP Address
Address of a client SMTP server as the basis for assessing of a client SMTP server as the basis for assessing whether to
whether to permit relay or delivery of a message. These permit relay or delivery of a message. These Addresses
Addresses identify the operator of an email service, rather identify the operator of an email service, rather than
than necessarily indicating the author of messages being sent necessarily indicating the author of messages being sent by
by that service. Use of an operator's domain name is a natural that service. Use of an operator's domain name is a natural
extension of this model. extension of this model.
Third-party -- An independent service might wish to certify an Third-party: An independent service might wish to certify an
author, a message or an operator, by providing its own author, a message or an operator, by providing its own
signature to a message. Hence, evaluation of the message will signature to a message. Hence, evaluation of the message will
be based upon the identity of that third-party, rather than any be based upon the identity of that third-party, rather than any
of the identities involved in creating or transferring the of the identities involved in creating or transferring the
message. Indeed, this model is already emerging among a number message. Indeed, this model is already emerging among a number
of reputation-vetting services and is similar to the way a of reputation-vetting services and is similar to the way a
credit card permits a customer to make purchases, based upon credit card permits a customer to make purchases, based upon
the reputation of the credit card company -- and its the reputation of the credit card company -- and its
willingness to issue the card. willingness to issue the card.
Ultimately, deciding where to sign a message will depend upon both Ultimately, deciding where to sign a message will depend upon both
the identity being used and tradeoffs among flexibility of uses, the identity being used and tradeoffs among flexibility of uses,
administrative control, and operational control. Deciding where to administrative control, and operational control. Deciding where to
verify a message will depend upon the intended use and similar verify a message will depend upon the intended use and similar
concerns about flexibility and control. A typical choice for concerns about flexibility and control. A typical choice for
reputation-related verification will be to place the signature reputation-related verification will be to place the signature
verification function "close" to the message-filtering engine. verification function "close" to the message-filtering engine.
5.3. Impact on Email Activities 4.3. Impact on Email Activities
5.3.1. Resources 4.3.1. Resources
Although cryptographic authentication is considered to be Although public-key cryptographic authentication is considered to be
computationally expensive, the real impact of a mechanism like DKIM computationally expensive, the real impact of a mechanism like DKIM
is remarkably small. Direct impact on CPU-load has been measured to can be remarkably small. Direct impact on CPU-load has been measured
be 10-15%. Mail handling tends to be I/O-intensive, so dedicated to be 10-15%. Mail handling tends to be I/O-intensive, so that
email platforms tend to have unused computational capacity. It is dedicated email platforms tend to have unused computational capacity.
therefore likely that no new hardware will be required for these It is therefore likely that no new hardware will be required for
systems to be able to add DKIM support. these systems to be able to add DKIM support.
5.3.2. Operations 4.3.2. Operations
The costs to deploy, administer and operate DKIM vary greatly, The costs to deploy, administer and operate DKIM vary greatly,
depending upon the placement of DKIM-related modules. The greatest depending upon the placement of DKIM-related modules. The greatest
flexibility comes from placing the modules as close as possible to flexibility comes from placing the modules as close as possible to
the end user. However this also imposes the greatest costs. The the end user. However this also imposes the greatest costs. The
most common scenarios are likely to be: most common scenarios are likely to be:
Boundary MTA -- Here, DKIM is used only for email external to the Boundary MTA: Here, DKIM is used only for email external to the
ADMD. Administration and operation is the simplest, but could ADMD. Administration and operation is the simplest, but could
cause problems for mobile users who are associated with the cause problems for mobile users who are associated with the
organization but must send mail using facilities that are organization but must send mail using facilities that are
independent of their home ADMD. It also provides no assistance independent of their home ADMD. It also provides no assistance
for inter-departmental accountability within the ADMD.. for inter-departmental accountability within the ADMD..
MSA/MDA (Department) -- Placing DKIM support at the points of MSA/MDA (Department): Placing DKIM support at the points of
submission and delivery increases the deployment costs but still submission and delivery increases the deployment costs but
keeps control within the ADMD's operational staff. It avoids the still keeps control within the ADMD's operational staff. It
considerable, added costs of having to enhance all of the MUAs. avoids the considerable, added costs of having to enhance all
This does not improve the lot of mobile users who submit from of the MUAs. This does not improve the lot of mobile users who
independent MSAs, but does provide full protection within the submit from independent MSAs, but does provide full protection
ADMD. within the ADMD.
MUA -- Obviously this can provide the most complete protection, but
at the cost of considerable added administrative effort. Worse,
there is extensive evidence that email infrastructure services
often perform changes to message content that can break a message
signature. Examples include transformation by the MSA to ensure
that the message is in full conformance with Internet standards
and transformation by Boundary MTAs, to ensure conformance with
organizational policies about external communications.
Placing DKIM support into the MUA is the only way to ensure that a
highly mobile user retains all of its benefits, in spite of these
concerns and having to send mail through independent MSAs.
TBD ... Challenge of mobile users. Server-resident folders -- web
or imap -- no problem. Laptop-resident folders, requires remote MSA
access or per-user keying and mobile-author awareness.
Key creation and replacement. Update DNS and signing component MUA: Obviously this can provide the most complete protection,
but at the cost of considerable added administrative effort.
Worse, there is extensive evidence that email infrastructure
services often perform changes to message content that can
break a message signature. Examples include transformation by
the MSA to ensure that the message is in full conformance with
Internet standards and transformation by Boundary MTAs, to
ensure conformance with organizational policies about external
communications.
5.3.3. Users 4.3.3. Mobile Users
TBD ... Challenge of mobile users. Server-resident folders -- web Mobile users often must post messages through MSAs that are not under
or imap -- no problem. Laptop-resident folders, requires remote MSA the control of the user's home ADMD. Placing DKIM signing into the
access or per-user keying and mobile-author awareness. MUA is the only way to ensure that a highly mobile user retains all
of its benefits, in spite of having to send mail through these
independent MSAs. However this leads to the administrative overhead
of having a DKIM DNS key selector record for each mobile user. For
mail reading, no changes are needed.
Challenge of mailing lists. Different list styles warrant different 4.3.4. Mailing Lists
signature policies.
Can be hidden from end-user; used by filter engine. Method and A mailing list takes delivery of a message and reposts it, usually
benefits for displaying to users unknown. with significant changes to the message. This will often break a
DKIM signature, although DKIM has some features to survive simple
mailing list modifications. For mailing lists that impose
substantial changes, it will be the responsibility of the list
operator to add their own DKIM signature.
5.4. Migrating from DomainKeys 4.4. Migrating from DomainKeys
5.4.1. Signing 4.4.1. Signing
DNS Records: DKIM is upward compatible with existing DomainKeys DNS Records: DKIM is upward compatible with existing DomainKeys
(DK) DNS records, so that a DKIM module does not automatically (DK) [I-D.delany-domainkeys-base] DNS records, so that a DKIM
require additional DNS administration! DKIM has enhanced the module does not automatically require additional DNS
DomainKeys DNS key record format by adding several optional administration! However, it should be noted that DKIM has
parameters. enhanced the DomainKeys DNS key record format by adding several
optional parameters.
Boundary MTA: Enforce signature policies and practices
> Boundary MTA: The principle use of DomainKeys is at Boundary
MTAs. Because no operational transition is ever instantaneous,
a signer SHOULD add a DKIM signature to a message that has a
DomainKeys signature, rather than replacing it, until such time
as DomainKeys receive-side support is sufficiently reduced.
With respect to signing policies, a reasonable, initial
approach is to use DKIM signatures in the same way as
DomainKeys signatures are already being use.
5.4.2. Verifying 4.4.2. Verifying
DNS Client: TBD DNS Client: DNS queries for the DKIM key record, use the same
Domain Name naming conventions and the same basic record
format. No changes to the DNS client should be required.
Verifying module: See "Signing Module". Verifying module: See "Signing Module".
5.4.3. Boundary MTA 4.4.3. Boundary MTA
Strip "local" signatures that are not local? Independent of whether a Boundary MTA is performing general message
filtering, a helpful practice is to have it check for DKIM signatures
that purport to be made with a domain name that belongs to the ADMD
of the Boundary MTA. If the signature does not validate, the MTA MAY
decide to delete the signature.
6. DKIM Service Architecture 5. Service Architecture
DKIM provides an end-to-end service for signing and verifying DKIM provides an end-to-end service for signing and verifying
messages that are in transit. It is divided into components that can messages that are in transit. It is divided into components that can
be performed using different, external services, such as for key be performed using different, external services (e.g., key
retrieval, although the basic DKIM operation provides an initial set. retrieval), although the basic DKIM operation provides an initial
set.
| |
| - RFC2822 Message | - RFC2822 Message
V V
+---------------------------------------------+ +---------------------------------------------+
+-----------+ | ORIGINATING OR RELAYING ADMD | +-----------+ | ORIGINATING OR RELAYING ADMD |
| | | ============================ | | Signer | | ============================ |
| Signer | | |
| Practices +......>| SIGN MESSAGE | | Practices +......>| SIGN MESSAGE |
| | | ...> ADD A SIGNATURE HEADER FIELD | +-----+-----+ | ...> ADD A SIGNATURE HEADER FIELD |
+-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) | . ...>| . GET (Domain, Selector, Priv-Key) |
. . | ... COMPUTE SIGNATURE | . / | ... COMPUTE SIGNATURE |
. V +----------------+----------------------------+ . V +----------------+----------------------------+
. +-------+ | - Message . +-------+ | - Message
. | | | 1*(Domain, Selector, . | Key | | 1*(Domain, Selector,
. | Key | | Sig) . | Store | [Internet] Sig)
. | Store | [Internet]
. | | |
. +---+---+ V . +---+---+ V
. . +---------------------------------------------+ . . +---------------------------------------------+
. . | RELAYING OR DELIVERING ADMD | . . | RELAYING OR DELIVERING ADMD |
. . | =========================== | . . | =========================== |
. . | |
. . | VERIFY MESSAGE (Verifier Practices) | . . | VERIFY MESSAGE (Verifier Practices) |
. . | ...> VERIFY A SIGNATURE HEADER FIELD | . . | ...> VERIFY A SIGNATURE HEADER FIELD |
. . | . GET A SIGNATURE | . . | . GET A SIGNATURE |
. .....>| . LOOKUP PUB-KEY (Domain, Selector) | . \...>| . LOOKUP PUB-KEY (Domain, Selector) |
. | . VERIFY SIGNATURE VALUE | . | . VERIFY SIGNATURE VALUE |
. | ... EVALUATE SIGNATURE CONSTRAINTS | . | ... EVALUATE SIGNATURE CONSTRAINTS |
. +-------------------+-------------------------+ . +-------------------+-------------------------+
. | - Verified Domain(s) . | - Verified Domain(s)
. V - [Report] . V - [Report]
. +---------------------------------------------+ . +---------------------------------------------+
. | | \............>| MESSAGE DISPOSITION |
. | MESSAGE DISPOSITION | ............>| SIGNER PRACTICES |
.............>| SIGNER PRACTICES | / | REPUTATION |
.............>| REPUTATION |
. | |
+-----+------+ +---------------------------------------------+ +-----+------+ +---------------------------------------------+
| |
| Reputation | | Reputation |
| |
+------------+> +------------+>
Figure 3: DKIM Service Architecture Figure 3: DKIM Service Architecture
Basic message processing divides between signing the message, Basic message processing is divided between signing the message,
validating the signature, and then performing further decision-making validating the signature, and then making further decisions based
based upon the validated signature. The component doing the signing upon the validated signature. The signing component applies whatever
applies whatever signing policies are in force, including ones that signing policies are in force, including ones that determine which
determine what private key to use. Validation may be performed by private key to use. Validation may be performed by any functional
any functional component along the relay and delivery path. The component along the relay and delivery path. Validators retrieve the
public key is retrieved, based upon the parameters stored in the public key based upon the parameters stored in the message. The
message. The example shows use of the validated identity for figure shows using the validated identity to assess an associated
assessing an associated reputation. However it could be applied for reputation, but it could be applied to other tasks, such as
other tasks, such as management tracking of mail. management tracking of mail.
7. Implementation Considerations
7.1. Development 6. Development
7.1.1. Coding Criteria for Cryptographic Applications 6.1. Coding Criteria for Cryptographic Applications
Correct implementation of a cryptographic algorithm is a necessary Correct implementation of a cryptographic algorithm is a necessary
but not a sufficient condition for coding of cryptographic but not a sufficient condition for coding of cryptographic
applications. Coding of cryptographic libraries requires close applications. Coding of cryptographic libraries requires close
attention to security considerations that are unique to cryptographic attention to security considerations that are unique to cryptographic
applications. applications.
In addition to the usual security coding considerations, such as In addition to the usual security coding considerations, such as
avoiding buffer or integer overflow and underflow, implementers avoiding buffer or integer overflow and underflow, implementers
should pay close attention to management of cryptographic private should pay close attention to management of cryptographic private
skipping to change at page 22, line 5 skipping to change at page 20, line 43
performance benefits, many cryptographic hardware devices provide performance benefits, many cryptographic hardware devices provide
robust and verifiable management of private keys. robust and verifiable management of private keys.
Fortunately appropriately designed and coded cryptographic libraries Fortunately appropriately designed and coded cryptographic libraries
are available for most operating system platforms under license terms are available for most operating system platforms under license terms
compatible with commercial, open source and free software license compatible with commercial, open source and free software license
terms. Use of standard cryptographic libraries is strongly terms. Use of standard cryptographic libraries is strongly
encouraged. These have been extensively tested, reduce development encouraged. These have been extensively tested, reduce development
time and support a wide range of cryptographic hardware. time and support a wide range of cryptographic hardware.
7.1.1.1. Signer 6.1.1. Signer
Signer implementations SHOULD provide a convenient means of Signer implementations SHOULD provide a convenient means of
generating DNS key records corresponding to the signer configuration. generating DNS key records corresponding to the signer configuration.
Support for automatic insertion of key records into the DNS is also Support for automatic insertion of key records into the DNS is also
highly desirable. If supported however such mechanism(s) MUST be highly desirable. If supported however such mechanism(s) MUST be
properly authenticated. properly authenticated.
Means of verifying that the signer configuration is compatible with Means of verifying that the signer configuration is compatible with
the signature policy is also highly desirable. the signature policy is also highly desirable.
Disclosure of a private signature key component to a third party Disclosure of a private signature key component to a third party
allows that third party to impersonate the sender. Protection of allows that third party to impersonate the sender. Protection of
private signature key data is therefore a critical concern. Signers private signature key data is therefore a critical concern. Signers
SHOULD support use of cryptographic hardware providing key management SHOULD support use of cryptographic hardware providing key management
features. features.
The import and export of private keys, and the ability to generate a The import and export of private keys, and the ability to generate a
Certificate Signing Request (CSR) for certificate registration are Certificate Signing Request (CSR) for certificate registration are
highly desirable. highly desirable.
7.1.1.2. Verifier 6.1.2. Verifier
Verifiers SHOULD treat the result of the verification step as an Verifiers SHOULD treat the result of the verification step as an
input to the message evaluation process rather than as providing a input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message, by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are unless the characteristics of the domain claiming responsibility are
known. known.
In particular, verifiers SHOULD NOT automatically assume that an In particular, verifiers SHOULD NOT automatically assume that an
email message that does not contain a signature, or that contains a email message that does not contain a signature, or that contains a
signature that does not validate, is forged. Verifiers should treat signature that does not validate, is forged. Verifiers should treat
a signature that fails to validate the same as if no signature were a signature that fails to validate the same as if no signature were
present. present.
7.1.2. Email Handlers 6.2. Email Infrastructure Agents
7.1.2.1. Mail User Agent
DKIM is designed to support deployment and use in email components
other than an MUA. However an MUA may also implement DKIM features
directly.
Outbound: If an MUA is configured to send email directly, rather
than relayed through an outbound MTA, the MUA SHOULD be considered
as if it were an outbound MTA for the purposes of DKIM. An MUA
MAY support signing even if mail is to be relayed through an
outbound MTA. In this case the signature applied by the MUA may
be in addition to or in place of the MTA signature.
Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA
path. An MUA MAY perform DKIM signature verification directly.
Such an MUA SHOULD allow for the case where mail is modified in
the inbound MTA path.
7.1.3. Mail Transfer Agent
It is expected that the most common venue for a DKIM implementation It is expected that the most common venue for a DKIM implementation
wil be a department or a boundary MTA. will be within the infrastructure of an organization's email service,
such as a department or a boundary MTA.
Outbound: An Outbound MTA should allow for automatic verification Outbound: An MSA or Outbound MTA should allow for automatic
of the MTA configuration such that the MTA can generate an verification of the MTA configuration such that the MTA can
operator alert if it determines that it is (1) an edge MTA, (2) generate an operator alert if it determines that it is (1) an
configured to send email messages that do not comply with the edge MTA, (2) configured to send email messages that do not
published DKIM sending policy. comply with the published DKIM sending policy.
An outbound MTA should be aware that users may employ MUAs that An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to take steps necessary add their own signatures and be prepared to take steps
to ensure that the message sent is in compliance with the necessary to ensure that the message sent is in compliance with
advertised email sending policy. the advertised email sending policy.
Inbound: An inbound MTA that does not support DKIM should avoid Inbound: An inbound MTA or an MDA that does not support DKIM
modifying messages in ways that prevent verification by other should avoid modifying messages in ways that prevent
MTAs, or MUAs to which the message may be forwarded. verification by other MTAs, or MUAs to which the message may be
forwarded.
Intermediaries: An email intermediary is both an inbound and Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the sections outbound MTA. Each of the requirements outlined in the
relating to MTAs apply. If the intermediary modifies a message in sections relating to MTAs apply. If the intermediary modifies
a way that breaks the signature, the intermediary SHOULD a message in a way that breaks the signature, the intermediary
* deploy abuse filtering measures on the inbound mail + SHOULD deploy abuse filtering measures on the inbound mail,
and
* remove all signatures that will be broken + MAY remove all signatures that will be broken
In addition the intermediary MAY: In addition the intermediary MAY:
* Verify the message signature prior to modification * Verify the message signature prior to modification.
* Incorporate an Authentication-Results header to report the * Incorporate an indication of the verification results into the
verification result. message, such as using an Authentication-Results header
[I-D.kucherawy-sender-auth-header].
* Sign the modified message including the Authentication-Results * Sign the modified message including the verification results
header (e.g., the Authentication-Results header).
7.2. Filtering 6.3. Filtering
Developers of filtering schemes designed to accept DKIM Developers of filtering schemes designed to accept DKIM
authentication results as input should be aware that their authentication results as input should be aware that their
implementations will be subject to counter-attack by email abusers. implementations will be subject to counter-attack by email abusers.
The efficacy of a filtering scheme cannot therefore be determined by The efficacy of a filtering scheme cannot therefore be determined by
reference to static test vectors alone; resistance to counter attack reference to static test vectors alone; resistance to counter attack
must also be considered. must also be considered.
Naive learning algorithms that only consider the presence or absence Naive learning algorithms that only consider the presence or absence
of a valid DKIM signature are vulnerable to an attack in which a of a valid DKIM signature are vulnerable to an attack in which a
skipping to change at page 24, line 30 skipping to change at page 23, line 5
If heuristic algorithms are employed, they should be trained on If heuristic algorithms are employed, they should be trained on
feature sets that sufficiently reveal the internal structure of the feature sets that sufficiently reveal the internal structure of the
DKIM responses. In particular the algorithm should consider the DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature, rather domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not. than the existence of a signature or not.
Unless a scheme can correlate the DKIM signature with accreditation Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of a DKIM signature SHOULD be or reputation data, the presence of a DKIM signature SHOULD be
ignored. ignored.
7.3. DNS Server 6.4. DNS Server
TBD
7.4. Accreditation service
TBD At a minimum, a DNS server that handles queries for DKIM key records
must perform server administrators to add free-form TXT records. It
would, of course, be better for provide them with a structured form,
to support the DKIM-specific fields.
8. Deployment 7. Deployment
This section describes the basic steps for introducing DKIM into an This section describes the basic steps for introducing DKIM into an
organization's email service operation. The considerations are organization's email service operation. The considerations are
divided between an organization's generating DKIM signatures divided between the generating DKIM signatures (Signing) and the
(Signing) and an organization's processing of messages that contain a processing of messages that contain a DKIM signature (Verifying).
DKIM signature (Verifying).
8.1. Signing 7.1. Signing
Creating messages that have DKIM signatures requires modification of Creating messages that have DKIM signatures requires modification of
only two portions of the email service: only two portions of the email service:
o Addition of relevant DNS information. o Addition of relevant DNS information.
o Addition of the signature by a trusted module within the o Addition of the signature by a trusted module within the
organization's email handling service. organization's email handling service.
The signing module uses the appropriate private key to create a The signing module uses the appropriate private key to create a
signature. The means by which the signing module obtains this key is signature. The means by which the signing module obtains this key is
not specified by DKIM. Given that DKIM is intended for use during not specified by DKIM. Given that DKIM is intended for use during
email transit, rather than for long-term storage, it is expected that email transit, rather than for long-term storage, it is expected that
keys will be changed regularly. Clearly this means that key keys will be changed regularly. Clearly this means that key
information should not be hard-coded into software. information should not be hard-coded into software.
8.1.1. DNS Records 7.1.1. DNS Records
A receiver attempting to validate a DKIM signature must obtain the A receiver attempting to validate a DKIM signature must obtain the
public key that is associated with the signature for that message. public key that is associated with the signature for that message.
The DKIM-Signature header in the message will specify the basic The DKIM-Signature header in the message will specify the basic
domain name doing the signing and the selector to be used for the domain name doing the signing and the selector to be used for the
specific public key. Hence, the relevant specific public key. Hence, the relevant
<selector>._domainkeys.<domain-name> DNS record needs to contain a <selector>._domainkeys.<domain-name> DNS record needs to contain a
DKIM-related RR that provides the public key information. DKIM-related resource record (RR) that provides the public key
information.
The administrator of the zone containing the relevant domain name The administrator of the zone containing the relevant domain name
adds this information. DNS administrative software varies adds this information. Initial DKIM DNS information is contained
considerably in its abilities to add new types of DNS records. within TXT RRs. DNS administrative software varies considerably in
Initial DKIM DNS information is contained within TXT RRs. its abilities to add new types of DNS records.
8.1.2. Signing Module 7.1.2. Signing Module
The module doing signing can be placed anywhere within an The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain (ADMD). organization's trusted Administrative Management Domain (ADMD);
Common choices are expected to be department-level posting and common choices are expected to be department-level posting and
delivering agents, as well as boundary MTAs to the open Internet. delivering agents, as well as boundary MTAs to the open Internet.
However, note that it is entirely acceptable to have signing and (Note that it is entirely acceptable for MUAs to perform signing and
validation be done by MUAs. Hence the choice among the modules validation.) Hence the choice among the modules depends upon
depends upon software development and administrative overhead software development and administrative overhead tradeoffs. One
tradeoffs. One perspective that helps resolve this choice is the perspective that helps resolve this choice is the difference between
difference between the flexibility of use by systems at, or close to, the flexibility of use by systems at (or close to) the MUA, versus
the MUA, versus the centralized control that is more easily obtained the centralized control that is more easily obtained by implementing
by implementing the mechanism "deeper" into the organization's email the mechanism "deeper" into the organization's email infrastructure,
infrastructure, such as at its boundary MTA. such as at its boundary MTA.
8.1.3. Signing Policies and Practices 7.1.3. Signing Policies and Practices
Every organization (ADMD) will have its own policies and practices Every organization (ADMD) will have its own policies and practices
for deciding when to sign messages and with what domain name and key for deciding when to sign messages and with what domain name and key
(selector). Examples include signing all mail, signing mail from (selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub- particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing domains. Given this variability, and the likelihood that signing
practices will change over time, it will be useful to have these practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information, decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software. rather than being more deeply coded into the signing software.
8.2. Verifying 7.2. Verifying
Verification is performed within an ADMD that wishes to make Verification is performed within an ADMD that wishes to make
assessments based upon the domain name used for a DKIM signature. assessments based upon the DKIM signature's domain name. Any
Any component within the ADMD that handles messages, whether in component within the ADMD that handles messages, whether in transit
transit or being delivered, can be appropriate to do the verifying. or being delivered, can do the verifying and subsequent assessments.
It must communicate the results of verification to another component Verification and assessment might occur within the same software
within the ADMD that performs the desired assessments. Verification mechanism, such as a Boundary MTA, or an MDA. Or they may be
and assessment might occur within the same software mechanism, such separated, such as having verification performed by the Boundary MTA
as a Boundary MTA, or an MDA. Or they may be separated, such as and assessment performed by the MDA.
having verification performed by the Boundary MTA and assessment
performed by the MDA.
As with the signing process, choice of service venues for As with the signing process, choice of service venues for
verification and assessment -- such as filtering or presentation to verification and assessment -- such as filtering or presentation to
the recipient user -- depend on trade-offs for flexibility, control, the recipient user -- depend on trade-offs for flexibility, control,
and operational ease. An added concern is that the linkage between and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: The assessment verification and assessment entails essential trust: the assessment
module must have a strong basis for believing that the verification module MUST have a strong basis for believing that the verification
information is correct. information is correct.
8.2.1. DNS Client 7.2.1. DNS Client
The primary means of publishing DKIM key information, initially, is The primary means of publishing DKIM key information, initially, is
through DNS TXT records. Some DNS client software might have initially through DNS TXT records. Some DNS client software might
problems obtaining these records. As DNS client software improves have problems obtaining these records; as DNS client software
this will not be a concern. improves this will not be a concern.
8.2.2. Boundary Enforcement 7.2.2. Boundary Enforcement
In order for an assessment module to trust the information it In order for an assessment module to trust the information it
receives about verification, it is essential to eliminate receives about verification (e.g., Authentication-Results headers),
verification information originating from outside the ADMD in which it MUST eliminate verification information originating from outside
the assessment mechanism operates. As a matter of friendly practice, the ADMD in which the assessment mechanism operates. As a matter of
it is equally important to make sure that verification information friendly practice, it is equally important to make sure that
generated within the ADMD not escape outside of it. verification information generated within the ADMD not escape outside
of it.
In most environments, the easiest way to enforce this stripping of In most environments, the easiest way to enforce this is to place
verification information is to place modules in the receiving and modules in the receiving and sending Boundary MTA(s) that strip any
sending Boundary MTA(s). For incoming mail, check for known means of existing verification information.
communicating verification information and remove it. The same
applies for outgoing mail.
8.3. Transition strategy 7.3. Mail User Agent
DKIM is designed to support deployment and use in email components
other than an MUA. However an MUA MAY also implement DKIM features
directly.
Outbound: If an MUA is configured to send email directly, rather
than relayed through an outbound MSA, the MUA SHOULD be
considered as if it were an outbound MTA for the purposes of
DKIM. An MUA MAY support signing even if mail is to be relayed
through an outbound MSA. In this case the signature applied by
the MUA may be in addition to any MSA signature.
Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA
path (e.g., an Authentication-Results header), or an MUA MAY
perform DKIM signature verification directly. A verifying MUA
SHOULD allow for the case where mail is modified in the inbound
MTA path.
7.4. Transition strategy
Deployment of a new signature algorithm without a 'flag day' requires Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that signers and verifiers can phase in a transition strategy such that signers and verifiers can phase in
support for the new algorithm independently and if necessary phase support for the new algorithm independently, and (if necessary) phase
out support for the old algorithm independently. out support for the old algorithm independently.
DKIM achieves these requirements through two features. First a [Note: this section assumes that a security policy mechanism exists.
signed message may contain multiple signatures created by the same It is subject to change.]
signer. Secondly the security policy layer allows the signing
algorithms in use to be advertised, thus preventing a downgrade
attack.
8.3.1. Signer transition strategy DKIM achieves these requirements through two features: First a signed
message may contain multiple signatures created by the same signer.
Secondly the security policy layer allows the signing algorithms in
use to be advertised, thus preventing a downgrade attack.
7.4.1. Signer transition strategy
Let the old signing algorithm be A, the new signing algorithm be B. Let the old signing algorithm be A, the new signing algorithm be B.
The sequence of events by which a Signer may introduce a new signing The sequence of events by which a Signer may introduce the new
algorithm, without disruption of service to legacy verifiers, is as signing algorithm B, without disruption of service to legacy
follows: verifiers, is as follows:
1. Signer signs with algorithm A 1. Signer signs with algorithm A
A. Signer advertises that it signs with algorithm A A. Signer advertises that it signs with algorithm A
2. Signer signs messages twice, first with algorithm A and algorithm 2. Signer signs messages twice, with both algorithm A and algorithm
B B
A. The signer tests new signing configuration A. The signer tests new signing configuration
B. Signer advertises that it signs with algorithm A and B. Signer advertises that it signs with algorithm A and
algorithm B algorithm B
3. Signer determines that support for Algorithm A is no longer 3. Signer determines that support for Algorithm A is no longer
necessary necessary
4. Signer determines that support for algorithm A is to be withdrawn 4. Signer determines that support for algorithm A is to be withdrawn
A. Signer removes advertisement for Algorithm A A. Signer removes advertisement for Algorithm A
B. Signer waits for cached copies of earlier signature policy to B. Signer waits for cached copies of earlier signature policy to
expire expire
C. Signer stops signing with Algorithm A C. Signer stops signing with Algorithm A
8.3.2. Verifier transition strategy 7.4.2. Verifier transition strategy
The actions of the verifier are independent of the signer's actions The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm A to be upgraded to support algorithm B without requiring algorithm A to be
withdrawn. The decisions of the verifier must make are therefore: withdrawn. The decisions of the verifier must make are therefore:
o The verifier MAY change the degree of confidence associated with o The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity signature algorithm provides a limited assurance of authenticity
at a given key strength. at a given key strength.
* A verifier MAY evaluate signature records in any order it * A verifier MAY evaluate signature records in any order it
chooses, including making use of the signature algorithm for chooses, including using the signature algorithm to choose the
choosing the order. order.
o The verifier MAY make a determination that Algorithm A does not o The verifier MAY make a determination that Algorithm A does not
offer a useful level of security, or that the cost of verifying offer a useful level of security, or that the cost of verifying
the signature is less than the value of doing so. the signature is less than the value of doing so.
* In this case the verifier ignores signatures created using the * In this case the verifier would ignore signatures created using
algorithm A and references to algorithm A in policy records are algorithm A and references to algorithm A in policy records
treated as if the algorithm were not implemented. would be treated as if the algorithm were not implemented.
o The verifier MAY decide to add support for additional signature o The verifier MAY decide to add support for additional signature
algorithms at any time. algorithms at any time.
* The verifier MAY add support for algorithm B at any time. * The verifier MAY add support for algorithm B at any time.
9. Operations 8. On-going Operations
This section describes the basic steps for the continued operation of This section describes the basic steps for operation of email systems
email systems that use DKIM. This section discusses keeping DKIM that use DKIM, after the capability has initially been deployed. The
going, as opposed to getting DKIM started. The primary primary considerations are:
considerations are: the upkeep of the selector files, and the
security of the private keys.
9.1. DNS Signature Record Deployment Considerations o the upkeep of the selector files, and
o the security of the private keys.
8.1. DNS Signature Record Deployment Considerations
The key point to remember is that the DNS DKIM selectors WILL and The key point to remember is that the DNS DKIM selectors WILL and
SHOULD be changed over time. Some reasons for changing DKIM SHOULD be changed over time. Some reasons for changing DKIM
selectors are well understood; others are still theoretical. There selectors are well understood; others are still theoretical. There
are several schemes that may be used to determine the policies for are several schemes that may be used to determine the policies for
changing DKIM selectors: changing DKIM selectors:
o time based o time based
o associations with clusters of servers o associations with clusters of servers
skipping to change at page 29, line 8 skipping to change at page 28, line 4
The key point to remember is that the DNS DKIM selectors WILL and The key point to remember is that the DNS DKIM selectors WILL and
SHOULD be changed over time. Some reasons for changing DKIM SHOULD be changed over time. Some reasons for changing DKIM
selectors are well understood; others are still theoretical. There selectors are well understood; others are still theoretical. There
are several schemes that may be used to determine the policies for are several schemes that may be used to determine the policies for
changing DKIM selectors: changing DKIM selectors:
o time based o time based
o associations with clusters of servers o associations with clusters of servers
o the use of third party signers o the use of third party signers
o security considerations o security considerations
9.1.1. Time Basis and Security Considerations 8.1.1. Time Basis and Security Considerations
The reason for changing the selector periodically is usually related The reason for changing the selector periodically is usually related
to the security exposure of a system. When the potential exposure of to the security exposure of a system. When the potential exposure of
the private keys associated with the DKIM selector have reached the private keys associated with the DKIM selector have reached
sufficient levels, the selector should be changed. (It is unclear sufficient levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in deciding when currently what kinds of metrics can be used to aid in deciding when
the exposure has reached sufficient levels to warrant changing the the exposure has reached sufficient levels to warrant changing the
selector.) selector.)
For example, For example,
skipping to change at page 29, line 44 skipping to change at page 28, line 39
o While the use of DKIM information is transient, keys with o While the use of DKIM information is transient, keys with
sufficient exposure do become stale and should be changed. sufficient exposure do become stale and should be changed.
o Whenever you make a substantial system change, such as bringing up o Whenever you make a substantial system change, such as bringing up
a new server, or making a major operating system change, you a new server, or making a major operating system change, you
should consider changing the selector. should consider changing the selector.
o Whenever there is either suspicion or evidence of the compromise o Whenever there is either suspicion or evidence of the compromise
of the system or the private keys, you should change the selector. of the system or the private keys, you should change the selector.
9.1.2. Server Clusters 8.1.2. Deploying New Selectors
TBD
9.1.3. Deploying New Selectors
A primary consideration in changing the selector is remembering to A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. If they are separate, both Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new the mail team and the DNS team will be involved in deploying new
selectors. selectors.
When deploying a new selector, it needs to be phased in: When deploying a new selector, it needs to be phased in:
1. generate the new public / private key pair and create a selector 1. generate the new public / private key pair and create a selector
skipping to change at page 30, line 11 skipping to change at page 29, line 4
A primary consideration in changing the selector is remembering to A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. If they are separate, both Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new the mail team and the DNS team will be involved in deploying new
selectors. selectors.
When deploying a new selector, it needs to be phased in: When deploying a new selector, it needs to be phased in:
1. generate the new public / private key pair and create a selector 1. generate the new public / private key pair and create a selector
record with the public key in it record with the public key in it
2. add the new selector record to your DNS 2. add the new selector record to your DNS
3. verify that the new selector record can be used to verify 3. verify that the new selector record can be used to verify
signatures signatures
4. turn on signing with the new private key 4. turn on signing with the new private key
5. optionally back up the old private key in a secure location 5. remove the old private key from your servers
6. remove the old private key from your servers
7. after a period of time, remove the old selector from your DNS 6. after a period of time, remove the old selector from your DNS
The time an unused selector should be kept in the DNS system is The time an unused selector should be kept in the DNS system is
dependent on the reason it's being changed. If the private key has dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable. immediately. Otherwise, longer periods are allowable.
9.1.4. Subdomain Considerations 8.1.3. Subdomain Considerations
TBD A Domain Name is the basis for making differential quality
assessments about a DKIM-signed message. It is reasonable for a
single organization to have a variety of very different activities,
which warrant a variety of very different assessments. A convenient
way to distinguish among such activities is to sign with different
domain names. That is, the organization should sign with sub-domain
names that are used for different organizational activities.
9.1.5. Third party Signature Delegations 8.1.4. Third party Signature Delegations
Allowing third parties to sign email from your domain opens your Allowing third parties to sign email from your domain opens your
system security to include the security of the third party's systems. system security to include the security of the third party's systems.
At a minimum, you should not allow the third parties to use the same At a minimum, you should not allow the third parties to use the same
selector and private key as your main mail system. It is recommended selector and private key as your main mail system. It is recommended
that each third party be given their own private key and selector. that each third party be given their own private key and selector.
This limits the exposure for any given private key, and minimizes the This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed. impact if any given private key were exposed.
9.2. Private Key Management 8.2. Private Key Management
The permissions of private key files must be carefully managed. If The permissions of private key files must be carefully managed. If
key management hardware support is available, it should be used. key management hardware support is available, it should be used.
Auditing software should be used to periodically verify that the Auditing software should be used to periodically verify that the
private key files remain secure. permissions on the private key files remain secure. [ Expand this
section? ]
9.3. Mailing List Management
[ Note: this section may be controversial. ] 8.3. Mailing list manager developers
A mailing list often provides facilities to its administrator to A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that are flowing through. The manipulate parts of the mail messages that flow through the list.
desired goal is that messages flowing through the mailing list will
be verifiable by the recipient, which means that either the mailing
list (or its MSA) must sign the message, or the mailing list must not
perform actions on the messages that will break existing DKIM
signatures. To avoid breaking existing signatures, a mailing list
system has these choices:
o A mailing list may add its own DKIM signature. If it does this,
it must make sure that it adds its signature after it performs any
content transformations to the message, such as adding a footer to
the body, adding a prefix to the body, modifying the subject
header, etc.
o If a mailing list does not add its own DKIM signature, it must not
modify any existing headers that are listed in an h= parameter of
any existing DKIM-Signature headers, nor may it add any footer
content to the body if there is no l= in any existing DKIM-
Signature headers.
o If a mailing list cannot add its own DKIM signature, and must
modify the headers or body in a way that will break verification
of existing DKIM-Signature headers, it should remove any existing
DKIM-Signature headers.
10. Outline Future Extensions
The design of DKIM is unapologetically focused on overcoming the need
for immediate deployment and achieving ubiquitous use in the near
future. As such, the original design discussions generally tok the
approach of 'if in doubt, leave it out'.
But the need to exclude consideration of these features in the near
term was in no way intended to preclude their development at a later
date. Nor is the lack of a specification describing the use of DKIM
with a different PKI infrastructure intended to indicate an intention
to develop similar capabilities within the DKIM framework at a future
date.
DKIM is an example of 'Design for Deployment', and the need to
support rapid deployment has been the overriding priority. It has
traditionally been asserted that deployment of a flawed cryptographic
protocol is an almost unacceptable risk, and that bad security is
worse than no security; experience demonstrates otherwise. Informing
users that email is insecure does not cause them to modify their
behavior to avoid dependence thereupon. Deployment of flawed
cryptographic security systems such as SSL and WEP has been rectified
far more quickly than deployment of protocols such as IPSEC or DNSSEC
where caution has prevailed.
One possible future for DKIM is that it becomes the starting point
for a new cryptographic infrastructure that eventually replaces
legacy systems including S/MIME and PGP. While this future is
certainly preferable to never achieving ubiquitous deployment of
strong cryptographic security in the Internet, it would certainly
take a long time to re-invent this particular wheel. Moreover the
deployment of the proposed DKIM enhancements would face political
opposition from the adherents to existing formats to be rendered
historical. A likely outcome of such a strategy is that the existing
two way standards stalemate between S/MIME and PGP would become a
three way stalemate.
Alternatively, another possible future is that DKIM provides the
'bootstrap' that enables ubiquitous use of the legacy infrastructure,
including the deployed base of PGP and S/MIME capable email clients
and the existing business infrastructure of commercial Certificate
Authorities. Such a strategy would make use of DKIM in conjunction
with existing PKI standards such as PKIX and XKMS and leverage
features of PGP and S/MIME where appropriate.
10.1. Introducing a new signing algorithm
Regardless of whether extension of the DKIM feature set is desirable,
the need to replace the signature algorithm is practically a
certainty. The RSA signature algorithm at best provides equivalent
security to an 80 bit symmetric cipher when used with a 1024 bit key
[cite]. Extending the key size to 2048 bits improves the cipher
strength to only 112 bit equivalence. Achieving 128 bit security
requires a minimum of 3072 bits. Achieving equivalent cipher
strength to a 192 bit symmetric algorithm requires a prohibitive key
size.
The choice of cryptographic algorithm affects the DKIM algorithm in
two important ways: First there is the difficulty of storing keys in
the DNS. Secondly there is the problem of handling larger
signatures.
The default DNS response packet limit of 512 bytes places an
effective upper bound of 4096 bits on a DKIM key. In practice the
need for packaging, meta-data and the desirability of using DNSSEC to
sign the record reduces the upper bound to no more than 2048 bits.
The size of the DKIM signature itself is a weaker constraint. Even
so, while 1024 and even 2048 bit signatures are likely to be
acceptable in most implementations larger signature sizes may become
prohibitive, particularly since the signature must be Base 64
encoded.
10.2. Possible future signature algorithm choices
ECC cryptography offers a means of implementing public key
cryptography using a key size and signature size that are each only
twice the size of the equivalent symmetric key algorithm.
While ECC offers clear technical advantages over algorithms based on
the difficulty on solving the discrete log problem in a finite field,
it is not possible at this point to be confident that a means of
applying ECC has been found that is consistent with the position on
intellectual property adopted by the DKIM working group.
The DSA signature algorithm based on the discrete log problem faces The desired goal is that messages flowing through the mailing list
the same key size limitations as RSA. Importantly for the design of will be verifiable by the recipient as being from the list, or
DKIM and DNSSEC however, the signature size is much smaller, the same failing that, as being from the individual list members.
size as for ECC algorithms.
It is likely that DSA would have received greater attention during In most cases, the list and/or its mail host SHOULD add its own DKIM
the design of DSA if key sizes greater than 512 bits and use of hash signature to list mail. This could be done in the list management
functions stronger than SHA-1 had been supported at the time. In software, in an outgoing MSA or MTA, or both. List management
March 2006 a proposed revision of the DSA signature algorithm software often makes modifications to messages that will break
answered these objections permitting larger key sizes and specifying incoming signatures, such as adding subject tags, adding message
the use of stronger hash functions (including SHA-256 and SHA 512). headers or footers, and adding, deleting, or reordering MIME parts.
While the advantages offered by DSA are not sufficient to warrant an By adding its own signature after these modifications, the list
immediate transition to the new algorithm at this late stage, it is provides a valid recognizable signature for list recipients.
highly probably that the algorithm will be employed by DNSSEC when
finally deployed.
10.3. Linkage to Other PKIs In some cases, mailing list software is simple enough that signatures
on incoming messages will still be valid after being remailed by the
list. It is still preferable that the list sign its mail so that
recipients can distinguish mail sent through the list from mail sent
directly by list members, but in the absence of a list signature, a
recipient may be able to recognize and use the signatures of list
members known to the recipient.
The principle limitations in DKIM are the lack of support for end- 9. Example Uses
user keying, the lack of support for long term verification of
signatures, and the lack of support for trusted third party issued
assertions. Each of these limitations is determined by the key
distribution mechanism rather than the signature format.
Although the DNS infrastructure could in principle be extended to A DKIM signature tells the signature verifier that the owner of a
support these features, this approach would require substantial particular domain name accepts responsibility for the message.
modifications that entirely negate the advantage of employing an Combining this information with information that allows the history
existing infrastructure. The point of using DNS is to reuse the DNS of the domain name owner to be assessed may allow processing the
infrastructure, not necessarily the DNS protocol. message, based on the probability that the message is likely to be
trustworthy, or not, without the need for heuristic content analysis.
The preferred approach to addressing these limitations is to support 9.1. Protection of Internal Mail
use of a PKI infrastructure designed to support these requirements
such as PKIX, PGP or XKMS.
10.4. Trusted Third Party Assertions One identity is particularly amenable to easy and accurate
assessment: The organization's own identity! Members of an
organization tend to trust messages that purport to be from within
that organization. However Internet Mail does not provide a
straightforward means of determining whether such mail is, in fact,
from within the organization. DKIM can be used to remedy this
exposure. If the organization signs all of its mail, then its
boundary MTAs can look for mail purporting to be from the
organization but which does not contain a valid signature. Such mail
can be presumed to be spurious.
A DKIM signature tells the signature verifier that the owner of a 9.2. Recipient-based Assessments
particular domain name accepts responsibility for the message.
Combining this information with information that allows the behavior
of the domain name owner to be predicted may allow the probability
that the message is abusive to be determined without the need for
heuristic content analysis.
Recipients of large volumes of email can generate reputation data for Recipients of large volumes of email can generate reputation data for
email senders internally. Recipients of smaller volumes of messages email senders internally. Recipients of smaller volumes of messages
are likely to need to acquire reputation data from a third party. In are likely to need to acquire reputation data from a third party. In
either case the use of reputation data is intrinsically limited to either case the use of reputation data is intrinsically limited to
email senders that have established a prior history of sending email senders that have established a prior history of sending
messages. messages.
Another commonly used technique for evaluating email senders is In fact, an email receiving service may be in a position to establish
accreditation. Most spam sent today is sent by criminals to further bilateral agreements with particular senders, such as business
a scheme that is unambiguously illegal. Spam demonstrates an partners or trusted bulk sending services. Although it is not
Internet equivalent of Gresham's law: the bad spam drives out the practical for each recipient to accredit every sender, definition of
merely irritating, the outright criminal drives out the bad. A core networks of explicit trust can be quite useful.
message is highly unlikely to be spam if: the email sender can
demonstrate that it is a legitimate business, and that it has
provided a legitimate address where legal process can be served. In
addition the accredited email sender may accept a legally binding
undertaking not to send spam and possibly post a performance bond
that is subject to forfeiture in case of default.
As with reputation data, a high volume email recipient may be in a
position to establish bilateral agreements with high volume senders.
Smaller recipients are not in a position to require accreditation,
nor is it practical for each large sender to accredit every sender.
Trusted Third Party accreditation services allow an email sender to
obtain an accreditation that is recognized by every email recipient
that recognizes the Trusted Third Party.
[Need use of both systems]
[Need means of advertising existence of positive reputation data]
10.5. Linkage to X.509 Certificates
The industry standard for distribution of Trusted Third Party data
tied to a public key is the X.509v3/PKIX standard. X.509 based PKI
is designed to support requirements such as long term archiving of
signatures, end entity signing and Trusted Third Party assertions.
Combining the DKIM signature format with the PKIX PKI infrastructure
provides an equivalent set of capabilities to S/MIME.
Two approaches may be used to inform signature verifiers that an
X.509 certificate has been issued that makes an assertion about the
signing key for a DKIM signature:
1. By means of an attribute in the key record
2. By means of a signature header q= parameter
Typical commercially issued digital certificates are considerably
larger (1-2 kb) than the 512 byte message size that DNS servers are
required to support as a minimum. Practical large scale PKI
deployment requires support for certificate chains in addition to the
end entity certificate. Publication of a URL for the certificate or
certificate chain is therefore a more appropriate approach than
storing the certificate data itself in the DNS.
The ability to support multiple key distribution mechanisms for the
same key is highly desirable. For example a signer may support DNS
based key distribution (for the convenience and efficiency of
transport based DKIM signature verifiers) as well as an X.509
certificate.
In other cases a signer may intentionally discourage transport
verification by only providing an X.509 certificate.
An X.509 application of particular interest is the use of DKIM as a
signature format for Secure Internet Letterhead (Letterhead).
Letterhead employs X.509 certificates containing a LOGOTYPE attribute
extension [LOGOTYPE] to identify the certificate subject and/or
issuer to the user by means of a brand image such as a corporate
logo. [PHB-NIST]
10.6. XKMS
XKMS is a key centric PKI that supports registration and location of
keys. XKMS is layered as a Web service and the existence of XKMS
service for a domain is typically advertised by means of a DNS SRV
record.
XKISS, the key location component of XKMS provides a superset of the
capabilities of the DKIM DNS key distribution mechanism. As XKMS is
layered on SOAP over HTTP over TCP/IP the overhead incurred in
retrieving keys through XKMS is substantially higher than the single
UDP request/response of DNS key distribution.
Like X.509 XKMS is designed to key management over time periods of
years and decades rather than days and supports the use of trusted
third parties. XKMS is designed to allow complexity to be
concentrated at the Web service as opposed to the client. A client
interacts with an XKMS service using request of the form 'provide a
key to verify signatures on messages sent by A using protocol B'.
XKMS may also be used as a gateway to one or more PKIs including an 9.2.1. Third-party Assessments
X.509 based PKI that makes use of sophisticated features such as
cross certification. The verifier may at its option rely on the XKMS
service to provide a trusted key or request the complete certificate
path allowing offline verification.
A signer may notify signature verifiers that a key may be retrieved For scaling efficiency, it is appealing to have Trusted Third Party
using XKMS by means of the q= attribute. The verifier may then assessment services, to allow an email sender to obtain a single
discover the corresponding XKMS service using the SRV mechanism as assessment that is then recognized by every email recipient that
set out in the XKMS specification. recognizes the Trusted Third Party.
10.7. Verification in the Client 9.3. DKIM Support in the Client
The DKIM specification is designed to support edge to edge The DKIM specification is expected to be used primarily between
authentication. The specification neither supports nor prohibits Boundary MTAs, or other infrastructure components of the originating
verification of DKIM signatures in the client. In particular the and receiving ADMDs. However there is nothing in DKIM that is
specification does not attempt to define client semantics for specific to those venues. In particular, it should be possible to
signatures or provide an exhaustive list of user interface security support signing and validating in MUAs.
considerations.
For client based verification to be practical, it is likely that a However, it is comment for components of an ADMD's email
client needs to be capable of determining that it is able to receive infrastructure to do violence to message, so as to render a DKIM
messages that do not get clobbered before coming to any conclusions signature invalid. Hence, users of MUAs that support DKIM signing
with respect to unsigned messages. and/or validating need a basis for knowing that their associated
email infrastructure will maintain signature validity.
DKIM requires that all verifiers treat messages with signatures that DKIM requires that all verifiers treat messages with signatures that
do not verify as if they are unsigned. If verification in the client do not verify as if they are unsigned. If verification in the client
is to be acceptable to users, it is also essential that successful is to be acceptable to users, it is also essential that successful
verification of a signature not result in a less than satisfactory verification of a signature not result in a less than satisfactory
user experience compared to leaving the message unsigned. user experience compared to leaving the message unsigned.
10.8. Per user signature 9.4. Per user signature
Although DKIM is designed to support domain level signatures, the
DKIM core design neither supports nor prohibits use of per user
signatures. A DKIM key record can specify restrictions on the email
addresses it can be used to sign for. These restrictions are not
intended to be exhaustive nor are detailed semantics or security
considerations set out for interpreting per user signatures. The
primary use that this feature is intended to support, is to allow a
company to delegate the signing authority for bulk marketing
communications without the risk of effectively delegating the
authority to sign contracts on behalf of the CEO.
For per user signing keys to provide value beyond this limited use
scenario, it is likely that additional requirements will be
necessary, such as the ability to perform long term validation of the
key. Linkage to some form of PKI is likely to be necessary.
In addition any scheme that involves maintenance of a significant
number of public keys will require infrastructure to support that
management. A system in which the end user is required to generate a
public key pair and transmit it to the DNS administrator out of band
is not likely to meet acceptance criteria for either usability or
security. At a minimum, a key registration protocol must be defined.
10.9. Encryption
DKIM is not designed to support encryption. A strong case can be
made for applying the DKIM style of transparent security, key centric
key management and domain level keying. It is not clear that re-
using the DKIM signature architecture is the best way to achieve this
goal.
The DKIM signature format in particular is designed to allow meta-
data to be attached to a message without modifying the content.
Content encryption by its very nature requires modification of the
message content. The message encryption formats of PGP and S/MIME
both solve the problem of message encryption perfectly adequately;
there is no reason to believe that a new effort in this space would
improve matters.
An architecture of this form would require development of an email
receiver security policy that allows a recipient to state that
encrypted email messages are acceptable and to specify the key
distribution infrastructure(s) by which the necessary encryption keys
may be discovered.
A policy infrastructure of this type is implicit in the XKMS
standard. One drawback to this approach is that policy distribution
and key distribution are conflated, an approach that is satisfactory
for message level encryption schemes such as PGP and S/MIME, but less
satisfactory for transport layer encryption such as SSL.
10.10. Reuse of Key Record
A number of proposals have been made that attempt to reuse the DKIM
key record. Architects considering this approach should be aware of
the advantages and limitations.
As a minimum each of the security considerations listed in the DKIM
specification should be considered and its possible relevance to the
proposed field of use carefully evaluated. Application of a security
mechanism outside the context in which it was originally designed for
is a principle cause of security failures.
DKIM is designed to meet the security needs of an application where
the cost of individual failures is insignificant or small. A single
spam in an email inbox is not a disaster, indeed it is no longer even
an irritation. For the long time spam sufferer who has seen their
inbox filled with hundreds or even thousands of spams, an occasional
failure may even be cause for satisfaction as a reminder of a
successfully vanquished foe.
One of the chief limitations of using DNS based key records is that
maintenance of DNS records is typically a network operations concern.
If the entity to which the public key corresponds is a network object
(e.g. a mail server), the use of DNS based key management is likely
to be satisfactory. If the entity is not a network related object
(e.g. an end user) a significant degree of pushback from network
administrators should be anticipated.
The design of DKIM is designed for rapid deployment in response to an
immediate need. As such many of the design decisions are not the
decisions that would be taken if the choice were unconstrained by the
limitations of the current legacy DNS. In particular the use of Base
64 encoded public keys distributed through TXT records is not ideal.
Applications that do not face the same constraints as DKIM should
carefully evaluate the feasibility of using the binary key record.
In particular an application predicated on the use of DNSSEC to
authenticate keys should assume support for DKIM binary key records.
10.11. Use of Policy Record Although DKIM's use of domain names is optimized for a scope of
organization-level signing, it is possible to have sub-domains and/or
selectors be administered in a way that supports per-user signing.
DKIM demonstrates the power of using the DNS to distribute security NOTE: As stated earlier, it is important to distinguish between use
policy information. It is not possible to achieve robust security of selectors, for differential administration of keys, versus sub-
unless the parties to a conversation know the security capabilities domains, for differential reputations.
and expectations of the other.
Any party proposing re-use of the DKIM policy record should carefully As a constraint on an authorized DKIM signing agent, their associated
consider whether their needs would be better met by proposing a key record can specify restrictions on the email addresses permitted
flexible security policy architecture in the DKIM style rather than to be signed with that domain and key. A typical intent of this
proposing ad-hoc extensions and variations. feature is to allow a company to delegate the signing authority for
bulk marketing communications without the risk of effectively
delegating the authority to sign messages purporting to come from the
domain-owning organization's CEO.
At a minimum any proposal for new security policy formats that make NOTE: Any scheme that involves maintenance of a significant number
use of the TXT record should employ a new policy prefix and ensure of public keys is likely to require infrastructure enhancements,
that mislabeled and wild-carded policy records are not accidentally to support that management. For example, a system in which the
misinterpreted. end user is required to generate a public key pair and transmit it
to the DNS administrator out of band is not likely to meet
acceptance criteria for either usability or security.
11. Acknowledgements 10. Acknowledgements
TBD TBD
12. { Misc Text -- Should go elsewhere, if used at all } 11. { Misc Text -- Should go elsewhere, if used at all }
DKIM permits the signing identity to be different from the identities DKIM permits the signing identity to be different from the identities
used for the author or the initial posting agent. This is essential, used for the author or the initial posting agent. This is essential,
for example, to enable support of signing by authorized third- for example, to enable support of signing by authorized third-
parties, and to permit signatures by email providers who are parties, and to permit signatures by email providers who are
otherwise independent of the domain name of the message author. otherwise independent of the domain name of the message author.
DKIM permits restricting the use of a signature key to particular DKIM permits restricting the use of a signature key to particular
types of services, such as only for email. This is helpful when types of services, such as only for email. This is helpful when
delegating signing authority, such as to a particular department or delegating signing authority, such as to a particular department or
skipping to change at page 39, line 48 skipping to change at page 33, line 9
In order to survive the vagaries of different email transfer systems, In order to survive the vagaries of different email transfer systems,
mechanisms like DKIM must evaluate the message data in some canonical mechanisms like DKIM must evaluate the message data in some canonical
form, such as treating a string of spaces as tabs as if they were a form, such as treating a string of spaces as tabs as if they were a
single space. DKIM has added the "relaxed" canonicalization in place single space. DKIM has added the "relaxed" canonicalization in place
of "nofws". of "nofws".
MUA UI considerations MUA UI considerations
key delegation/ 3rd party key delegation/ 3rd party
13. References 12. Informative References
13.1. References -- Normative [I-D.delany-domainkeys-base]
Delany, M., "Domain-based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)",
draft-delany-domainkeys-base-06 (work in progress),
July 2006.
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM) Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-06 (work in progress), Signatures", draft-ietf-dkim-base-10 (work in progress),
October 2006. February 2007.
[I-D.ietf-dkim-threats] [I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006. in progress), May 2006.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [I-D.kucherawy-sender-auth-header]
April 2001. Kucherawy, M., "Message Header for Indicating Sender
Authentication Status",
13.2. Informative References draft-kucherawy-sender-auth-header-04 (work in progress),
February 2007.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
Object Security Services", RFC 1848, October 1995. Object Security Services", RFC 1848, October 1995.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996. Exchange Formats", RFC 1991, August 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001. "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
skipping to change at page 42, line 7 skipping to change at page 35, line 7
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Phillip Hallam-Baker Phillip Hallam-Baker
VeriSign Inc. VeriSign Inc.
Email: pbaker@verisign.com Email: pbaker@verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 179 change blocks. 
837 lines changed or deleted 558 lines changed or added

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