draft-ietf-dkim-deployment-01.txt   draft-ietf-dkim-deployment-02.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational P. Hallam-Baker Intended status: Informational P. Hallam-Baker
Expires: August 28, 2008 VeriSign Inc. Expires: May 7, 2009 VeriSign Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
February 25, 2008 E. Siegel
Constant Contact, Inc.
November 3, 2008
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-01 draft-ietf-dkim-deployment-02
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 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008. This Internet-Draft will expire on May 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) allows an organization to take
with a message and provides a means of verifying that the association responsibility for transmitting a message, in a way that can be
is legitimate. [RFC4871] DKIM defines a domain-level authentication validated by a recipient. The organization can be the author's, the
framework for email using public-key cryptography and key server originating sending site, an intermediary, or one of their agents. A
technology. This permits verifying the source or intermediary for a message can contain multiple signatures, from the same or different
message, as well as the contents of messages. The ultimate goal of organizations involved with the message. DKIM defines a domain-level
this framework is to permit a signing domain to assert responsibility digital signature authentication framework for email, using public
for sending a message, thus proving and protecting the identity key cryptography, using the domain name service as its key server
associated with the message and the integrity of the messages itself, technology [RFC4871]. This permits verification of a responsible
while retaining the functionality of Internet email as it is known organization, as well as the integrity of the message contents. DKIM
today. Such protection of email identity may assist in the global will also provide a mechanism that permits potential email signers to
control of "spam" and "phishing". This document provides publish information about their email signing practices; this will
permit email receivers to make additional assessments about messages.
DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing. This document provides
implementation, deployment, operational and migration considerations implementation, deployment, operational and migration considerations
for DKIM. for DKIM.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Generation, Storage, and Management . . . . . . . . . . . 3
2.1. DKIM Signing Software . . . . . . . . . . . . . . . . . . 3 2.1. General Coding Criteria for Cryptographic Applications . . 3
2.2. General Coding Criteria for Cryptographic Applications . . 3 2.2. Key Generation and Storage . . . . . . . . . . . . . . . . 4
2.3. Mailing List Manager Software . . . . . . . . . . . . . . 4 2.3. DNS Signature Record Deployment and Maintenance
2.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 5 Considerations . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Filtering Software . . . . . . . . . . . . . . . . . . . . 6 3. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. DNS Server Software . . . . . . . . . . . . . . . . . . . 6 3.1. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Signature Transition Strategy . . . . . . . . . . . . . . 12
3.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Key Management Deployment . . . . . . . . . . . . . . . . 9 4.1. Verifier . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 4.2. DNS Client . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 11 4.3. Boundary Enforcement . . . . . . . . . . . . . . . . . . . 15
3.6. Transition Strategy . . . . . . . . . . . . . . . . . . . 12 4.4. Filtering Software . . . . . . . . . . . . . . . . . . . . 15
3.7. Migrating from DomainKeys . . . . . . . . . . . . . . . . 13 5. DKIM Deployment Considerations for Email Agents . . . . . . . 15
4. On-going Operations . . . . . . . . . . . . . . . . . . . . . 14 5.1. Email Infrastructure Agents . . . . . . . . . . . . . . . 15
4.1. DNS Signature Record Installation Considerations . . . . . 14 5.2. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 17
4.2. Private Key Management . . . . . . . . . . . . . . . . . . 16 6. Migrating from DomainKeys . . . . . . . . . . . . . . . . . . 17
5. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Protection of Internal Mail . . . . . . . . . . . . . . . 17 6.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Recipient-based Assessments . . . . . . . . . . . . . . . 17 7. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 18 7.1. Protection of Internal Mail . . . . . . . . . . . . . . . 18
5.4. Per user signatures . . . . . . . . . . . . . . . . . . . 18 7.2. Recipient-based Assessments . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.4. Per user signatures . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Informative References . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 11. Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
There are many areas to be considered when deploying DomainKeys There are many areas to be considered when deploying DomainKeys
Identified Mail (DKIM). This document provides practical tips for: Identified Mail (DKIM). This document provides practical tips for:
those who are developing DKIM software, mailing list managers, those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing DNS servers; those who are deploying DKIM software, keys, mailing
list software, and migrating from DomainKeys; and those who are list software, and migrating from DomainKeys; and those who are
responsible for the on-going operations of an email infrastructure responsible for the on-going operations of an email infrastructure
that has deployed DKIM. that has deployed DKIM.
2. Development The document is organized aorund the key concepts related to DKIM.
Within each section, additional considerations specific to
2.1. DKIM Signing Software development, deployment, or ongoing operations are highlighted where
appropriate.
Signer implementations SHOULD provide a convenient means of [[anchor2: maybe this is a good place to mention the possibility of
generating DNS key records corresponding to the signer configuration. collecting verification history for selectors domains as a means of
Support for automatic insertion of key records into the DNS is also observing over time behaviour of signers for the purpose of asserting
highly desirable. If supported however, such mechanism(s) MUST be local reputation]]
properly authenticated.
A means of verifying that the signer configuration is compatible with 2. Key Generation, Storage, and Management
the signature policy is also highly desirable.
Disclosure of a private signature key component to a third party DKIM defines a domain-level digital signature authentication
allows that third party to impersonate the sender. The protection of framework for email, using public key cryptography, using the domain
private signature key data is therefore a critical concern. Signers name service as its key server technology [RFC4871]. This section
SHOULD support use of cryptographic hardware providing key management covers considerations around generating, deploying, and managing the
features. public and private keys required for DKIM to function.
2.2. General Coding Criteria for Cryptographic Applications 2.1. General Coding Criteria for Cryptographic Applications
NOTE: This section could possibly be changed into a reference to NOTE: This section could possibly be changed into a reference to
something else, such as another rfc. something else, such as another rfc.
Correct implementation of a cryptographic algorithm is a necessary Correct implementation of a cryptographic algorithm is a necessary
but not a sufficient condition for the coding of cryptographic but not a sufficient condition for the 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
keys and session keys, ensuring that these are correctly initialized keys and session keys, ensuring that these are correctly initialized
and disposed of. and disposed of.
Operating system mechanisms that permit the confidentiality of Operating system mechanisms that permit the confidentiality of
private keys to be protected against other processes SHOULD be used private keys to be protected against other processes should be used
when available. In particular, great care MUST be taken when when available. In particular, great care must be taken when
releasing memory pages to the operating system to ensure that private releasing memory pages to the operating system to ensure that private
key information is not disclosed to other processes. key information is not disclosed to other processes.
Certain implementations of public key algorithms such as RSA may be Certain implementations of public key algorithms such as RSA may be
vulnerable to a timing analysis attack. vulnerable to a timing analysis attack.
Support for cryptographic hardware providing key management Support for cryptographic hardware providing key management
capabilities is strongly encouraged. In addition to offering capabilities is strongly encouraged. In addition to offering
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.
2.3. Mailing List Manager Software 2.2. Key Generation and Storage
A mailing list often provides facilities to its administrator to 2.2.1. Assignment of Selectors
manipulate parts of the mail messages that flow through the list.
The desired goal is that messages flowing through the mailing list
will be verifiable by the recipient as being from the list, or
failing that, as being from the individual list members.
In most cases, the list and/or its mail host SHOULD add its own DKIM Selectors Selectors are assigned according to the administrative
signature to list mail. This could be done in the list management needs of the signing domain, such as for rolling over to a new key
software, in an outgoing MSA or MTA, or both. List management or for delegating of the right to authenticate a portion of the
software often makes modifications to messages that will break namespace to a trusted third party.
incoming signatures, such as adding subject tags, adding message
headers or footers, and adding, deleting, or reordering MIME parts.
By adding its own signature after these modifications, the list
provides a verifiable, recognizable signature for list recipients.
In some cases, the modifications made by the mailing list software Examples include: jun2005.eng._domainkey.example.com
are simple enough that signatures on incoming messages will still be
verifiable after being remailed by the list. It is still preferable
that the list sign its mail so that recipients can distinguish
between mail sent through the list and mail sent directly to a list
member. In the absence of a list signature, a recipient may still be
able to recognize and use the original signatures of the list
members.
2.4. Email Infrastructure Agents widget.promotion._domainkey.example.com
It is expected that the most common venue for a DKIM implementation NOTE: It is intended that assessments of DKIM identities be based
will be within the infrastructure of an organization's email service, on the domain name, and not include the selector. This permits
such as a department or a boundary MTA. the selector to be used only for key administration, rather than
having an effect on reputation assessment.
Outbound: An MSA or Outbound MTA should allow for the automatic [[anchor7: The reputation of a selector could become relevant if
verification of the MTA configuration such that the MTA can it is known to have "gone rogue" before the DNS owner has a chance
generate an operator alert if it determines that it is (1) an to published a new zone update which contains a revoked key.]]
edge MTA, and (2) configured to send email messages that do not
comply with the published DKIM sending policy.
An outbound MTA should be aware that users may employ MUAs that 2.2.2. Third Party Key Management
add their own signatures and be prepared to take steps
necessary to ensure that the message sent is in compliance with
the advertised email sending policy.
Inbound: An inbound MTA or an MDA that does not support DKIM ????????????????
should avoid modifying messages in ways that prevent
verification by other MTAs, or MUAs to which the message may be
forwarded.
An inbound MTA or an MDA may incorporate an indication of the [[anchor9: what are we trying to cover here? The case where a 3rd
verification results into the message, such as using an party generates keys and provides the public key to the domain owner
Authentication-Results header. to publish? Or the case where the domain owner generates keys and
[I-D.kucherawy-sender-auth-header] provides the private key to the third party? Either way, I think we
need some discussion of 1st vs. 3rd party (preferably that the
distinction has little relevance except in the presence of ADSP,
since otherwise the reputation of the signing domain and not the 1st
or 3rd party nature of it is what is relevant.]]
Intermediaries: An email intermediary is both an inbound and 3rd party generates the public / private key pair and sends the
outbound MTA. Each of the requirements outlined in the public key to be published in the DNS.
sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary
+ SHOULD deploy abuse filtering measures on the inbound mail, 2.2.3. Storing Public Keys: DNS Server Software Considerations
and
+ MAY remove all signatures that will be broken At a minimum, a DNS server that handles queries for DKIM key records
must allow the server administrators to add free-form TXT records.
It would be better if the the DKIM records could be entered using a
structured form, supporting the DKIM-specific fields.
In addition the intermediary MAY: 2.2.4. Private Key Management: Deployment and Ongoing Operations
+ Verify the message signature prior to modification. The permissions of private key files must be carefully managed. If
key management hardware support is available, it should be used.
Auditing software should be used periodically to verify that the
permissions on the private key files remain secure.
+ Incorporate an indication of the verification results into 2.3. DNS Signature Record Deployment and Maintenance Considerations
the message, such as using an Authentication-Results header.
[I-D.kucherawy-sender-auth-header]
+ Sign the modified message including the verification results
(e.g., the Authentication-Results header).
2.5. Filtering Software Even with use of the DNS, one challenge is that DNS record management
is usually operated by an administrative staff that is different from
those who operate an organization's email service. In order to
ensure that DKIM DNS records are accurate, this imposes a requirement
for careful coordination between the two operations groups.
Developers of filtering schemes designed to accept DKIM The key point to remember is that the DNS DKIM selectors WILL and
authentication results as input should be aware that their should be changed over time. Some reasons for changing DKIM
implementations will be subject to counter-attack by email abusers. selectors are well understood, while others are still theoretical.
The efficacy of a filtering scheme cannot therefore be determined by There are several schemes that may be used to determine the policies
reference to static test vectors alone; resistance to counter attack for changing DKIM selectors:
must also be considered.
Naive learning algorithms that only consider the presence or absence o time based
of a verified DKIM signature, without considering more information
about the message, are vulnerable to an attack in which a spammer or
other malefactor signs all their mail, thus creating a large negative
value for presence of a DKIM signature in the hope of discouraging
widespread use.
If heuristic algorithms are employed, they should be trained on o associations with clusters of servers
feature sets that sufficiently reveal the internal structure of the o the use of third party signers
DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not.
Unless a scheme can correlate the DKIM signature with accreditation o security considerations
or reputation data, the presence of a DKIM signature SHOULD be
ignored.
2.6. DNS Server Software A potential mistake in creating the DNS key record is the erroneous
use of a backslash (\) in the definition. Some implementations
reading a zone file allow a backslash to be used anywhere, stripping
any such occurrences. Other implementations only allow it to be used
in front of an quotation mark, storing the backslash in the record
and causing a syntax error to be generated by DKIM implementations
reading the record.
At a minimum, a DNS server that handles queries for DKIM key records 2.3.1. Time Basis and Security Considerations
must allow the server administrators to add free-form TXT records.
It would be better if the the DKIM records could be entered using a
structured form, supporting the DKIM-specific fields.
3. Deployment The reason for changing the selector periodically is usually related
to the security exposure of a system. When the potential exposure of
the private keys associated with the DKIM selector have reached
sufficient levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in deciding when
the exposure has reached sufficient levels to warrant changing the
selector.)
This section describes the basic steps for introducing DKIM into an For example,
organization's email service operation. The considerations are
divided between the generating DKIM signatures (Signing) and the
processing of messages that contain a DKIM signature (Verifying).
3.1. Signing o Selectors should be changed more frequently on systems that are
widely exposed, than on systems that are less widely exposed. For
example, a gateway system that has numerous externally-accessible
services running on it is more widely exposed than one that ONLY
runs a mail server.
o Selectors should be changed more frequently on operating systems
that are under wide attack.
o While the use of DKIM information is transient, keys with
sufficient exposure do become stale and should be changed.
o Whenever you make a substantial system change, such as bringing up
a new server, or making a major operating system change, you
should consider changing the selector.
[[anchor14: above you refer to changing the key, here you refer to
changing the selector; they have not been explicitly declared as
synonymous so this could be confusing]]
o Whenever there is either suspicion or evidence of the compromise
of the system or the private keys, you should change the selector.
2.3.2. Deploying New Selectors
A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new
selectors.
When deploying a new selector, it needs to be phased in:
1. Generate the new public / private key pair and create a new
selector record with the public key in it.
2. Add the new selector record to your DNS.
3. Verify that the new selector record can be used to verify
signatures.
4. Turn on signing with the new private key.
5. Remove the old private key from your servers.
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
dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable.
[[anchor16: interesting; should we have included a "u=" ('until') tag
on key records allowing an advertised "good until" timestamp?]]
2.3.3. Subdomain Considerations
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.
2.3.4. Delegating Signing Authority to a Third party
Allowing third parties to sign email from your domain opens your
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
selector and private key as your main mail system. It is recommended
that each third party be given its own private key and selector.
This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed.
3. Signing
3.1. Deployment
Creating messages that have DKIM signatures requires a modification Creating messages that have DKIM signatures requires a modification
to only two portions of the email service: to 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
skipping to change at page 7, line 41 skipping to change at page 9, line 4
its abilities to add new types of DNS records. its abilities to add new types of DNS records.
3.1.2. Signing Module 3.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.
(Note that it is entirely acceptable for MUAs to perform signing and (Note that it is entirely acceptable for MUAs to perform signing and
verification.) Hence the choice among the modules depends upon verification.) Hence the choice among the modules depends upon
software development and administrative overhead tradeoffs. One software development and administrative overhead tradeoffs.
perspective that helps resolve this choice is the difference between
the flexibility of use by systems at (or close to) the MUA, versus
the centralized control that is more easily obtained by implementing
the mechanism "deeper" into the organization's email infrastructure,
such as at its boundary MTA.
3.1.3. Signing 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
(selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing
practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software.
3.2. Verifying
3.2.1. Verifier
Verifiers SHOULD treat the result of the verification step as an
input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are
known.
In particular, verifiers SHOULD NOT automatically assume that an
email message that does not contain a signature, or that contains a
signature that does not verify, is forged. Verifiers should treat a
signature that fails to verify the same as if no signature were
present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP
Verification is performed within an ADMD that wishes to make
assessments based upon the DKIM signature's domain name. Any
component within the ADMD that handles messages, whether in transit
or being delivered, can do the verifying and subsequent assessments.
Verification and assessment might occur within the same software
mechanism, such as a Boundary MTA, or an MDA. Or they may be
separated, such as having verification performed by the Boundary MTA
and assessment performed by the MDA.
As with the signing process, choice of service venues for
verification and assessment -- such as filtering or presentation to
the recipient user -- depend on trade-offs for flexibility, control,
and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: the assessment
module MUST have a strong basis for believing that the verification
information is correct.
3.2.2. DNS Client
The primary means of publishing DKIM key information, initially, is
initially through DNS TXT records. Some DNS client software might
have problems obtaining these records; as DNS client software
improves this will not be a concern.
3.2.3. Boundary Enforcement
In order for an assessment module to trust the information it
receives about verification (e.g., Authentication-Results headers),
it MUST eliminate verification information originating from outside
the ADMD in which the assessment mechanism operates. As a matter of
friendly practice, it is equally important to make sure that
verification information generated within the ADMD not escape outside
of it.
In most environments, the easiest way to enforce this is to place
modules in the receiving and sending Boundary MTA(s) that strip any
existing verification information.
3.3. Key Management Deployment
More to be added
3.3.1. First Party Key Management
Selectors 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 [[anchor23: See earlier note about signing by MUAs being a security
concern]] One perspective that helps resolve this choice is the
difference between the flexibility of use by systems at (or close to)
the MUA, versus the centralized control that is more easily obtained
by implementing the mechanism "deeper" into the organization's email
infrastructure, such as at its boundary MTA.
widget.promotion._domainkey.example.com 3.1.3. DKIM Signing Software Development
NOTE: It is intended that assessments of DKIM identities be based Signer implementations should provide a convenient means of
on the domain name, and not include the selector. This permits generating DNS key records corresponding to the signer configuration.
the selector to be used only for key administration, rather than Support for automatic insertion of key records into the DNS is also
having an effect on reputation assessment. highly desirable. If supported however, such mechanism(s) must be
properly authenticated.
3.3.2. Third Party Key Management A means of verifying that the signer configuration is compatible with
the signature policy is also highly desirable.
???????????????? 3rd party generates the public / private key pair Disclosure of a private signature key component to a third party
and sends the public key to be published in the DNS. allows that third party to impersonate the sender. The protection of
private signature key data is therefore a critical concern. Signers
should support use of cryptographic hardware providing key management
features.
3.3.3. Signer Actions 3.1.3.1. Signer Actions
All Signers SHOULD: All Signers should:
o Include any existing Sender header field in the signed header o Include any existing Sender header field in the signed header
field list, if the Sender header field exists. field list, if the Sender header field exists.
Signers wishing to avoid the use of Third-Party Signatures SHOULD do o ...
Signers wishing to avoid the use of Third-Party Signatures should do
everything listed above, and also: everything listed above, and also:
o Include the Sender header field name in the header field list o Include the Sender header field name in the header field list
("h=" tag) under all circumstances, even if the Sender header ("h=" tag) under all circumstances, even if the Sender header
field does not exist in the header block. This prevents another field does not exist in the header block. This prevents another
entity from adding a Sender header field. entity from adding a Sender header field.
o Publish Signing Practices that do not sanction the use of Third- o Publish Signing Practices that do not sanction the use of Third-
Party Signatures. Party Signatures.
3.4. Mailing Lists 3.1.4. Signing 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
(selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing
practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software.
3.2. Mailing Lists
A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that flow through the list.
The desired goal is that messages flowing through the mailing list
will be verifiable by the recipient as being from the list, or
failing that, as being from the individual list members.
There are several forms of mailing lists, which interact with signing There are several forms of mailing lists, which interact with signing
in different ways. in different ways.
o "Verbatim" mailing lists send messages without modification o "Verbatim" mailing lists send messages without modification
whatsoever. They are often implemented as MTA-based aliases. whatsoever. They are often implemented as MTA-based aliases.
Since they do not modify the message, signatures are unaffected Since they do not modify the message, signatures are unaffected
and will continue to verify. It is not necessary for the and will continue to verify. It is not necessary for the
forwarder to re-sign the message; however, some may choose to do forwarder to re-sign the message; however, some may choose to do
so in order to certify that the message was sent through the list. so in order to certify that the message was sent through the list.
skipping to change at page 10, line 40 skipping to change at page 10, line 49
signed by the Mailing List Manager itself, if they are signed at signed by the Mailing List Manager itself, if they are signed at
all. all.
o "Resending" mailing lists receive a message, modify it (often to o "Resending" mailing lists receive a message, modify it (often to
add "unsubscribe" information or advertising), and immediately add "unsubscribe" information or advertising), and immediately
resend that message to the subscription list. They are resend that message to the subscription list. They are
problematic because they usually do not change the "From" header problematic because they usually do not change the "From" header
field of the message, but they do invalidate the signature in the field of the message, but they do invalidate the signature in the
process of modifying the message. process of modifying the message.
In most cases, the list and/or its mail host should add its own DKIM
signature to list mail. This could be done in the list management
software, in an outgoing MSA or MTA, or both. List management
software often makes modifications to messages that will break
incoming signatures, such as adding subject tags, adding message
headers or footers, and adding, deleting, or reordering MIME parts.
By adding its own signature after these modifications, the list
provides a verifiable, recognizable signature for list recipients.
In some cases, the modifications made by the mailing list software
are simple enough that signatures on incoming messages will still be
verifiable after being remailed by the list. It is still preferable
that the list sign its mail so that recipients can distinguish
between mail sent through the list and mail sent directly to a list
member. In the absence of a list signature, a recipient may still be
able to recognize and use the original signatures of the list
members.
The first two cases act in obvious ways and do not require further The first two cases act in obvious ways and do not require further
discussion. The remainder of this session applies only to the third discussion. The remainder of this session applies only to the third
case. case.
3.4.1. Mailing List Manager Actions 3.2.1. Mailing List Manager Actions
Mailing List Managers should make every effort to ensure that Mailing List Managers should make every effort to ensure that
messages that they relay and which have Valid Signatures upon receipt messages that they relay and which have Valid Signatures upon receipt
also have Valid Signatures upon retransmission. In particular, also have Valid Signatures upon retransmission. In particular,
Mailing List Managers that modify the message in ways that break Mailing List Managers that modify the message in ways that break
existing signatures SHOULD: existing signatures should:
o Verify any existing DKIM Signatures. A DKIM-aware Mailing List o Verify any existing DKIM Signatures. A DKIM-aware Mailing List
Manager MUST NOT re-sign an improperly signed message in such a Manager must NOT re-sign an improperly signed message in such a
way that would imply that the existing signature is acceptable. way that would imply that the existing signature is acceptable.
o Apply regular anti-spam policies. A Mailing List Manager SHOULD o Apply regular anti-spam policies. A Mailing List Manager should
apply message content security policy just as they would messages apply message content security policy just as would be done to
destined for an individual user's mailbox. In fact, a Mailing messages destined for an individual user's mailbox. In fact, a
List Manager might apply a higher standard to messages destined to Mailing List Manager might apply a higher standard to messages
a mailing list than would normally be applied to individual destined to a mailing list than would normally be applied to
messages. individual messages.
NON-NORMATIVE RATIONALE: Since reputation will accrue to signers, NON-NORMATIVE RATIONALE: Since reputation will accrue to signers,
Mailing List Managers should verify the source and content of Mailing List Managers should verify the source and content of
messages before they are willing to sign lest their reputation be messages before they are willing to sign lest their reputation be
sullied by nefarious parties. sullied by nefarious parties.
o Add a Sender header field using a valid address pointing back to o Add a Sender header field using a valid address pointing back to
the Mailing List Administrator or an appropriate agent (such as an the Mailing List Administrator or an appropriate agent (such as an
"owner-" or a "-request" address). "owner-" or a "-request" address).
o Sign the resulting message with a signature that is valid for the o Sign the resulting message with a signature that is valid for the
Sender header field address. The Mailing List Manager SHOULD NOT Sender header field address. The Mailing List Manager should NOT
sign messages for which they are unwilling to accept sign messages for which they are unwilling to accept
responsibility. responsibility.
Mailing List Managers MAY: Mailing List Managers MAY:
o Reject messages with signatures that do not verify or are o Reject messages with signatures that do not verify or are
otherwise Suspicious. otherwise Suspicious.
3.5. Mail User Agent [[anchor29: Is "Suspicious" still a formal term in DKIM?]]
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.
It is common for components of an ADMD's email infrastructure to do 3.3. Signature Transition Strategy
violence to a message, such as to render a DKIM signature invalid.
Hence, users of MUAs that support DKIM signing and/or verifying need
a basis for knowing that their associated email infrastructure will
not break a signature.
3.6. Transition Strategy [[anchor31: I'm not entirely clear what is meant by "algorithm"
beyond the combination of key, selector, and signing parameters
included in the DKIMSignature header. Unless I'm way off base, I
think this section belongs either here under "Signing", or in section
1 under "Key Generation, Storage, and Management". Either way, we
should be more clear about what is meant by the term "signature
algorithm".]]
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.
[Note: this section assumes that a security policy mechanism exists. [Note: this section assumes that a security policy mechanism exists.
It is subject to change.] It is subject to change.]
DKIM achieves these requirements through two features: First a signed [[anchor32: safe to presume ADSP?]]
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.
3.6.1. Signer transition strategy DKIM achieves these requirements through two features: First, a
signed message may contain multiple signatures created by the same
signer. Second, the security policy layer allows the signing
algorithms in use to be advertised, thus preventing a downgrade
attack.
Let the old signing algorithm be A, the new signing algorithm be B. 3.3.1. Signer transition strategy
The sequence of events by which a Signer may introduce the new
Let the old signing algorithm be A and the new signing algorithm be
B. The sequence of events by which a Signer may introduce the new
signing algorithm B, without disruption of service to legacy signing algorithm B, without disruption of service to legacy
verifiers, is as 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, with both 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 either algorithm A or B. Signer advertises that it signs with either algorithm A or
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
skipping to change at page 13, line 4 skipping to change at page 13, line 16
A. The signer tests new signing configuration A. The signer tests new signing configuration
B. Signer advertises that it signs with either algorithm A or B. Signer advertises that it signs with either algorithm A or
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
3.6.2. Verifier transition strategy 3.3.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
skipping to change at page 13, line 42 skipping to change at page 14, line 10
* In this case the verifier would ignore signatures created using * In this case the verifier would ignore signatures created using
algorithm A and references to algorithm A in policy records algorithm A and references to algorithm A in policy records
would be 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.
3.7. Migrating from DomainKeys 4. Verifying
3.7.1. Signing 4.1. Verifier
DNS Records: DKIM is upwardly compatible with existing Verifiers should treat the result of the verification step as an
DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module input to the message evaluation process rather than as providing a
does not automatically require additional DNS administration! final decision. The knowledge that a message is authentically sent
However DKIM has enhanced the DomainKeys DNS key record format by a domain does not say much about the legitimacy of the message,
by adding several additional optional parameters. unless the characteristics of the domain claiming responsibility are
known.
Boundary MTA: The principle use of DomainKeys is at Boundary In particular, verifiers should NOT automatically assume that an
MTAs. Because no operational transition is ever instantaneous, email message that does not contain a signature, or that contains a
it is not adviseable for existing DomainKeys signers to switch signature that does not verify, is forged. Verifiers should treat a
to DKIM without continuing to perform DomainKeys signing. A signature that fails to verify the same as if no signature were
signer should add a DKIM signature to a message that also has a present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP
DomainKeys signature, 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 used.
3.7.2. Verifying Verification is performed within an ADMD that wishes to make
assessments based upon the DKIM signature's domain name. Any
component within the ADMD that handles messages, whether in transit
or being delivered, can do the verifying and subsequent assessments.
Verification and assessment might occur within the same software
mechanism, such as a Boundary MTA, or an MDA. Or they may be
separated, such as having verification performed by the Boundary MTA
and assessment performed by the MDA.
DNS Client: DNS queries for the DKIM key record, use the same As with the signing process, choice of service venues for
Domain Name naming conventions as were used for DomainKeys, and verification and assessment -- such as filtering or presentation to
the same basic record format. No changes to the DNS client the recipient user -- depend on trade-offs for flexibility, control,
should be required. and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: the assessment
module must have a strong basis for believing that the verification
information is correct.
Verifying module: See the section on Signing above. 4.2. DNS Client
4. On-going Operations The primary means of publishing DKIM key information, initially, is
through DNS TXT records. Some DNS client software might have
problems obtaining these records; as DNS client software improves
this will not be a concern.
This section describes the basic steps for operation of email systems 4.3. Boundary Enforcement
that use DKIM, after the capability has initially been deployed. The
primary considerations are:
o the upkeep of the selector files, and In order for an assessment module to trust the information it
receives about verification (e.g., Authentication-Results header
fields), it must eliminate verification information originating from
outside the ADMD in which the assessment mechanism operates. As a
matter of friendly practice, it is equally important to make sure
that verification information generated within the ADMD not escape
outside of it.
o the security of the private keys. In most environments, the easiest way to enforce this is to place
modules in the receiving and sending Boundary MTA(s) that strip any
existing verification information.
4.1. DNS Signature Record Installation Considerations 4.4. Filtering Software
Even with use of the DNS, one challenge is that DNS record management Developers of filtering schemes designed to accept DKIM
is usually operated by an administrative staff that is different from authentication results as input should be aware that their
those who operate an organization's email service. In order to implementations will be subject to counter-attack by email abusers.
ensure that DKIM DNS records are accurate, this imposes a requirement The efficacy of a filtering scheme cannot therefore be determined by
for careful coordination between the two operations groups. reference to static test vectors alone; resistance to counter attack
must also be considered.
The key point to remember is that the DNS DKIM selectors WILL and Naive learning algorithms that only consider the presence or absence
SHOULD be changed over time. Some reasons for changing DKIM of a verified DKIM signature, without considering more information
selectors are well understood, while others are still theoretical. about the message, are vulnerable to an attack in which spammers or
There are several schemes that may be used to determine the policies other malefactors sign all their mail, thus creating a large negative
for changing DKIM selectors: value for presence of a DKIM signature in the hope of discouraging
widespread use.
o time based If heuristic algorithms are employed, they should be trained on
feature sets that sufficiently reveal the internal structure of the
DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not.
o associations with clusters of servers Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of a DKIM signature should be
ignored.
o the use of third party signers 5. DKIM Deployment Considerations for Email Agents
o security considerations 5.1. Email Infrastructure Agents
4.1.1. Time Basis and Security Considerations It is expected that the most common venue for a DKIM implementation
will be within the infrastructure of an organization's email service,
such as a department or a boundary MTA.
The reason for changing the selector periodically is usually related Outbound: An MSA or Outbound MTA should allow for the automatic
to the security exposure of a system. When the potential exposure of verification of the MTA configuration such that the MTA can
the private keys associated with the DKIM selector have reached generate an operator alert if it determines that it is (1) an
sufficient levels, the selector should be changed. (It is unclear edge MTA, and (2) configured to send email messages that do not
currently what kinds of metrics can be used to aid in deciding when comply with the published DKIM sending policy.
the exposure has reached sufficient levels to warrant changing the
selector.)
For example, An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to take steps
necessary to ensure that the message sent is in compliance with
the advertised email sending policy.
o Selectors should be changed more frequently on systems that are [[anchor42: MUAs being able to sign is a security
widely exposed, than on systems that are less widely exposed. For consideration; MUAs are more prone to vulnerabilities, so an
example, a gateway system that has numerous externally-accessible MUA having direct access to signing keys is a security concern;
services running on it, is more widely exposed than one that ONLY general MUA vulnerability came up during the IETF Security
runs a mail server. Directorate review of draft-kucherawy-sender-auth-header]]
o Selectors should be changed more frequently on operating systems Inbound: An inbound MTA or an MDA that does not support DKIM
that are under wide attack. should avoid modifying messages in ways that prevent
verification by other MTAs, or MUAs to which the message may be
forwarded.
o While the use of DKIM information is transient, keys with An inbound MTA or an MDA may incorporate an indication of the
sufficient exposure do become stale and should be changed. verification results into the message, such as using an
Authentication-Results header field.
[I-D.kucherawy-sender-auth-header]
o Whenever you make a substantial system change, such as bringing up Intermediaries: An email intermediary is both an inbound and
a new server, or making a major operating system change, you outbound MTA. Each of the requirements outlined in the
should consider changing the selector. sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary
o Whenever there is either suspicion or evidence of the compromise + should deploy abuse filtering measures on the inbound mail,
of the system or the private keys, you should change the selector. and
4.1.2. Deploying New Selectors + MAY remove all signatures that will be broken
A primary consideration in changing the selector is remembering to In addition the intermediary MAY:
change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new
selectors.
When deploying a new selector, it needs to be phased in: + Verify the message signature prior to modification.
1. Generate the new public / private key pair and create a new + Incorporate an indication of the verification results into
selector record with the public key in it. the message, such as using an Authentication-Results header
field. [I-D.kucherawy-sender-auth-header]
+ Sign the modified message including the verification results
(e.g., the Authentication-Results header field).
2. Add the new selector record to your DNS. 5.2. Mail User Agent
3. Verify that the new selector record can be used to verify DKIM is designed to support deployment and use in email components
signatures. other than an MUA. However an MUA MAY also implement DKIM features
directly.
4. Turn on signing with the new private key. Outbound: If an MUA is configured to send email directly, rather
than relay it 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.
5. Remove the old private key from your servers. 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 field), 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.
6. After a period of time, remove the old selector from your DNS. It is common for components of an ADMD's email infrastructure to do
violence to a message, such as to render a DKIM signature invalid.
Hence, users of MUAs that support DKIM signing and/or verifying need
a basis for knowing that their associated email infrastructure will
not break a signature.
The time an unused selector should be kept in the DNS system is 6. Migrating from DomainKeys
dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable.
4.1.3. Subdomain Considerations 6.1. Signing
A Domain Name is the basis for making differential quality DNS Records: DKIM is upwardly compatible with existing
assessments about a DKIM-signed message. It is reasonable for a DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module
single organization to have a variety of very different activities, does not automatically require additional DNS administration.
which warrant a variety of very different assessments. A convenient However DKIM has enhanced the DomainKeys DNS key record format
way to distinguish among such activities is to sign with different by adding several additional optional parameters.
domain names. That is, the organization should sign with sub-domain
names that are used for different organizational activities.
4.1.4. Delegating Signing Authority to a Third party [[anchor46: Explicit "g=" has different meaning in DomainKeys
and DKIM, which has been an interoperability issue in the past
(DomainKeys interprets that as "match any" while DKIM
interprets it as "match none")]]
Boundary MTA: The principal use of DomainKeys is at Boundary
MTAs. Because no operational transition is ever instantaneous,
it is not adviseable for existing DomainKeys signers to switch
to DKIM without continuing to perform DomainKeys signing. A
signer should add a DKIM signature to a message that also has a
DomainKeys signature, 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 used.
Allowing third parties to sign email from your domain opens your 6.2. Verifying
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
selector and private key as your main mail system. It is recommended
that each third party be given their own private key and selector.
This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed.
4.2. Private Key Management DNS Client: DNS queries for the DKIM key record use the same
Domain Name naming conventions as were used for DomainKeys, and
the same basic record format. No changes to the DNS client
should be required.
The permissions of private key files must be carefully managed. If Verifying module: See the section on Signing above.
key management hardware support is available, it should be used.
Auditing software should be used to periodically verify that the
permissions on the private key files remain secure.
5. Example Uses 7. Example Uses
A DKIM signature tells the signature verifier that the owner of a A DKIM signature tells the signature verifier that the owner of a
particular domain name accepts responsibility for the message. particular domain name accepts responsibility for the message.
Combining this information with information that allows the history Combining this information with information that allows the history
of the domain name owner to be assessed may allow processing the of the domain name owner to be assessed may allow processing the
message, based on the probability that the message is likely to be message, based on the probability that the message is likely to be
trustworthy, or not, without the need for heuristic content analysis. trustworthy, or not, without the need for heuristic content analysis.
5.1. Protection of Internal Mail 7.1. Protection of Internal Mail
One identity is particularly amenable to easy and accurate One identity is particularly amenable to easy and accurate
assessment: The organization's own identity. Members of an assessment: The organization's own identity. Members of an
organization tend to trust messages that purport to be from within organization tend to trust messages that purport to be from within
that organization. However Internet Mail does not provide a that organization. However Internet Mail does not provide a
straightforward means of determining whether such mail is, in fact, straightforward means of determining whether such mail is, in fact,
from within the organization. DKIM can be used to remedy this from within the organization. DKIM can be used to remedy this
exposure. If the organization signs all of its mail, then its exposure. If the organization signs all of its mail, then its
boundary MTAs can look for mail purporting to be from the boundary MTAs can look for mail purporting to be from the
organization but does not contain a verifiable signature. Such mail organization but does not contain a verifiable signature. Such mail
can be presumed to be spurious. can be presumed to be spurious.
WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN
SIGNATURE???? SIGNATURE???? Need to include some of the breakage examples from
ADSP spec.
5.2. Recipient-based Assessments 7.2. Recipient-based Assessments
Recipients of large volumes of email can internally generate Recipients of large volumes of email can internally generate
reputation data for email senders. Recipients of smaller volumes of reputation data for email senders. Recipients of smaller volumes of
messages are likely to need to acquire reputation data from a third messages are likely to need to acquire reputation data from a third
party. In either case the use of reputation data is intrinsically party. In either case the use of reputation data is intrinsically
limited to email senders that have established a prior history of limited to email senders that have established a prior history of
sending messages. sending messages.
In fact, an email receiving service may be in a position to establish In fact, an email receiving service may be in a position to establish
bilateral agreements with particular senders, such as business bilateral agreements with particular senders, such as business
partners or trusted bulk sending services. Although it is not partners or trusted bulk sending services. Although it is not
practical for each recipient to accredit every sender, the definition practical for each recipient to accredit every sender, the definition
of core networks of explicit trust can be quite useful. of core networks of explicit trust can be quite useful.
5.2.1. Third-party Reputation and Accreditation Services 7.2.1. Third-party Reputation and Accreditation Services
For scaling efficiency, it is appealing to use Trusted Third Party For scaling efficiency, it is appealing to use Trusted Third Party
reputation and accreditation services, to allow an email sender to reputation and accreditation services, to allow an email sender to
obtain a single assessment that is then recognized by every email obtain a single assessment that is then recognized by every email
recipient that recognizes the Trusted Third Party. recipient that recognizes the Trusted Third Party.
5.3. DKIM Support in the Client 7.3. DKIM Support in the Client
The DKIM specification is expected to be used primarily between The DKIM specification is expected to be used primarily between
Boundary MTAs, or other infrastructure components of the originating Boundary MTAs, or other infrastructure components of the originating
and receiving ADMDs. However there is nothing in DKIM that is and receiving ADMDs. However there is nothing in DKIM that is
specific to those venues. In particular, it should be possible to specific to those venues. In particular, it should be possible to
support signing and verifying in MUAs. support signing and verifying in MUAs.
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.
5.4. Per user signatures 7.4. Per user signatures
Although DKIM's use of domain names is optimized for a scope of Although DKIM's use of domain names is optimized for a scope of
organization-level signing, it is possible to administer sub-domains organization-level signing, it is possible to administer sub-domains
and/or selectors in a way that supports per-user signing. and/or selectors in a way that supports per-user signing.
NOTE: As stated earlier, it is important to distinguish between the NOTE: As stated earlier, it is important to distinguish between the
use of selectors for differential administration of keys, versus use of selectors for differential administration of keys, versus
the use of sub-domains for differential reputations. the use of sub-domains for differential reputations. It's also
probably a good idea to note that receivers are unlikely to pay
attention to reputation at a user granularity even if it's
technically feasible to publish it.
As a constraint on an authorized DKIM signing agent, their associated As a constraint on an authorized DKIM signing agent, its associated
key record can specify restrictions on the email addresses permitted key record can specify restrictions on the email addresses permitted
to be signed with that domain and key. A typical intent of this to be signed with that domain and key. A typical intent of this
feature is to allow a company to delegate the signing authority for feature is to allow a company to delegate the signing authority for
bulk marketing communications without the risk of effectively bulk marketing communications without the risk of effectively
delegating the authority to sign messages purporting to come from the delegating the authority to sign messages purporting to come from the
domain-owning organization's CEO. domain-owning organization's CEO.
NOTE: Any scheme that involves maintenance of a significant number NOTE: Any scheme that involves maintenance of a significant number
of public keys is likely to require infrastructure enhancements, of public keys is likely to require infrastructure enhancements,
to support that management. For example, a system in which the to support that management. For example, a system in which the
end user is required to generate a public key pair and transmit it 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 to the DNS administrator out of band is not likely to meet
acceptance criteria for either usability or security. acceptance criteria for either usability or security.
6. Security Considerations 8. Security Considerations
TBD TBD
7. IANA Considerations 9. IANA Considerations
TBD TBD
8. Acknowledgements 10. Acknowledgements
TBD TBD
9. Informative References 11. Informative References
[I-D.ietf-openpgp-rfc2440bis] [I-D.ietf-openpgp-rfc2440bis]
Callas, J., "OpenPGP Message Format", Callas, J., "OpenPGP Message Format",
draft-ietf-openpgp-rfc2440bis-22 (work in progress), draft-ietf-openpgp-rfc2440bis-22 (work in progress),
April 2007. April 2007.
[I-D.kucherawy-sender-auth-header] [I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", Message Authentication Status",
draft-kucherawy-sender-auth-header-11 (work in progress), draft-kucherawy-sender-auth-header-17 (work in progress),
February 2008. October 2008.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 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.
skipping to change at page 21, line 5 skipping to change at page 22, line 28
Email: pbaker@verisign.com Email: pbaker@verisign.com
Dave Crocker Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Ellen Siegel
Constant Contact, Inc.
1601 Trapelo Rd, Ste 329
Waltham, MA 02451
USA
Email: esiegel@constantcontact.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 21, line 44 skipping to change at line 1035
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 121 change blocks. 
418 lines changed or deleted 488 lines changed or added

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