wdiff draft-ietf-dkim-overview-01.txt draft-ietf-dkim-overview-02.txt

DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories
Expires: December 27, 2006
Intended status: Informational D. Crocker
Expires: April 25, 2007 Brandenburg InternetWorking
P. Hallam-Baker
VeriSign Inc.
June 25,
October 22, 2006

DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-01.txt
draft-ietf-dkim-overview-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 27, 2006. April 25, 2007.

Abstract

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 to permit verification of technology. This permits verifying the source and or
intermediary for a message, as well as the contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). messages. The
ultimate goal of this framework is to permit a signing domain to
assert responsibility for a message, thus proving and protecting message sender the
identity associated with the message and the integrity of the
messages they convey itself, while retaining the functionality of Internet email
as it is known today. Proof and Such protection of email identity,
including repudiation and non-repudiation, may assist
in the global control of "spam" and "phishing". This document
provides an overview of DomainKeys Identified Mail DKIM and describes how it can fit into overall a
messaging systems, service, how it relates to other IETF message signature technologies,
technologies. It also includes implementation and migration considerations, and outlines potential DKIM applications
and future extensions.
considerations.

Note

This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. About This Document 5
2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6
3. DKIM's Goals . 4
1.2. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . 4
1.3. Outline Potential DKIM Applications . . . . . . . 7
3.1. Treat verification failure as if unsigned. . . . . 7
2. DKIM Within Existing Internet Email . . . 8
3.2. Domain-level assurance . . . . . . . . . . 7
2.1. Review of Internet Mail Service Architecture . . . . . . . 7
2.2. Where to Place DKIM Functions 8
3.3. Incremental adoption . . . . . . . . . . . . . . 10
2.3. Impact on Email Activities . . . . 8
3.4. Minimal infrastructure . . . . . . . . . . . . 11
2.4. Migrating from DomainKeys . . . . . 9
3.5. Transparent signature . . . . . . . . . . . 12
2.5. { Misc Text -- Should go elsewhere, if used at all } . . . 13
3. DKIM Within Existing Internet Email . . . . 9
3.6. Security policy . . . . . . . . . 14
3.1. Review of Internet Mail Service Architecture . . . . . . . 14
3.2. Where to Place DKIM Functions . . . . . 9
4. A Quick Overview of DKIM . . . . . . . . . 17
3.3. Impact on Email Activities . . . . . . . . . . 9
4.1. What is a DKIM signature? . . . . . . 17
3.4. Migrating from DomainKeys . . . . . . . . . . 10
4.2. The Selector construct . . . . . . 18
3.5. { Misc Text -- Should go elsewhere, if used at all } . . . 19
4. DKIM Service Architecture . . . . . . . . 10
4.3. Who validates the signature? . . . . . . . . . . 21
5. Relationship to previous Message Signature Technologies . . . 23
5.1. Transparent Signature . 10
4.4. What does DKIM NOT do? . . . . . . . . . . . . . . . . . 23
5.2. Treat verification failure as if unsigned. 11
4.5. Does DKIM eliminate anonymity for email? . . . . . . . . 24
5.3. Legacy Client Semantics 11
4.6. Outline potential DKIM applications . . . . . . . . . . . 11
4.7. What is a DKIM policy? . . . . . . 25
5.4. Key Centric PKI . . . . . . . . . . . 11
5. DKIM Within Existing Internet Email . . . . . . . . . . 25
5.5. Domain Level Assurance . . . 12
5.1. Review of Internet Mail Service Architecture . . . . . . 12
5.2. Where to Place DKIM Functions . . . . . . . . . . . . 27
5.6. Security Policy . . 15
5.3. Impact on Email Activities . . . . . . . . . . . . . . . 16
5.4. Migrating from DomainKeys . . . . 27 . . . . . . . . . . . . 18
6. DKIM Service Architecture . . . . . . . . . . . . . . . . . . 19
7. Implementation Considerations . . . . . . . . . . . . . . . . 28
6.1. 21
7.1. Development . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Deployment 21
7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Operations 24
7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 24
7.4. Accreditation service . 29
7. Outline Future Extensions . . . . . . . . . . . . . . . . . 24
8. Deployment . 30
7.1. Introducing a new signing algorithm . . . . . . . . . . . 31
7.2. Possible future signature algorithm choices . . . . . . . 31
7.3. Transition strategy . . . . . . . 24
8.1. Signing . . . . . . . . . . . . 32
7.4. Linkage to Other PKIs . . . . . . . . . . . . . 24
8.2. Verifying . . . . . 33
7.5. Trusted Third Party Assertions . . . . . . . . . . . . . . 34
7.6. Linkage to X.509 Certificates . . . . . 26
8.3. Transition strategy . . . . . . . . . 35
7.7. XKMS . . . . . . . . . . 27
9. Operations . . . . . . . . . . . . . . . . . 35
7.8. Verification in the Client . . . . . . . . . 28
9.1. DNS Signature Record Deployment Considerations . . . . . 28
10. Outline Future Extensions . . 36
7.9. Per user signature . . . . . . . . . . . . . . . . 31
10.1. Introducing a new signing algorithm . . . . 37
7.10. Encryption . . . . . . . 32
10.2. Possible future signature algorithm choices . . . . . . . 32
10.3. Linkage to Other PKIs . . . . . . . . . . 37
7.11. Reuse of Key Record . . . . . . . . 33
10.4. Trusted Third Party Assertions . . . . . . . . . . . 38
7.12. Use of Policy Record . . 33
10.5. Linkage to X.509 Certificates . . . . . . . . . . . . . . 34
10.6. XKMS . . . 38
8. What Needs To Be Moved Here From the Base Doc? . . . . . . . . 39
9. Acknowledgements . . . . . . . . . . . . . . . 35
10.7. Verification in the Client . . . . . . . . 39
10. Informative References . . . . . . . 36
10.8. Per user signature . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . 36
10.9. Encryption . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . 37
10.10. Reuse of Key Record . . . . . 42

1. Introduction

1.1. About This Document

This document provides an overview of DomainKeys Identified Mail
(DKIM). It provides information for: those who are adopting DKIM;
those who are developing DKIM; . . . . . . . . . . . . . . 37
10.11. Use of Policy Record . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
12. { Misc Text -- Should go elsewhere, if used at all } . . . . . 38
12.1. What Needs To Be Moved Here From the Base Doc? . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. References -- Normative . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41

1. Introduction

This document provides an overview of DomainKeys Identified Mail
(DKIM). It is intended for those who are adopting, developing, or
deploying DKIM; and DKIM. It also will be helpful for those who are
considering extending DKIM, either into other areas or to provide support
additional features. This document Overview does not provide information on
threats to DKIM or email, or details on the implementation. Such information protocol specifics, which
can be found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim-
threats] Nor does this [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats],
respectively. The document describe how to solve the assumes a background in basic network
security technology and services.

NOTE: It must be stressed that neither this document nor DKIM
attempt to provide solutions to the world's problems with spam,
phish, virii, worms, joe jobs, etc.

[ NOTE: DKIM creates one, basic tool
in what needs to be a number large arsenal of sections in this document are just placeholders tools, for now ]

1.2. A Quick Overview improving the
safety of Internet mail. However by itself, DKIM

1.2.1. Axiom: Ubiquitous Authentication is Good

DKIM builds on previous work in not
sufficient to that task and this Overview does not pursue the form of Domain Keys, Identified
Internet Mail, Authenticated Sender, Meta-Mail, etc. The starting
point for all
issues of integrating DKIM into these technologies, and now DKIM, is the belief that
authenticating email larger efforts. Rather, it
is a good thing basic introduction to do in the technology and its deployment.

NOTE: A number of itself. It has sections in this document are just placeholders,
for now.

There have been pointed out that it is unlikely that RFC 822 [RFC0822] would
pass today without some form of strong authentication mechanism.
DKIM provides such a strong authentication mechanism.

The ultimate goal of DKIM is to achieve a situation where four other efforts at standardizing an email
authentication is ubiquitous
signature scheme:

o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989]
and the unsigned email becomes the
exception the rule, eventually transformed into MIME Object Security Services in
1995 [RFC1848]. Today, they are only of historical interest.

o Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
first released in 1991.[RFC1991] A later version was standardized
as is the case today. Only when OpenPGP. [RFC3156]

o RSA Security, the majority holder of
Internet email is authenticated is it possible to make interesting
conclusions about the lack of authentication.

It follows then that a new message signature scheme is required patent rights to
meet the goal principle
public key cryptography algorithm, independently developed Secure
MIME (S/MIME) to transport a PKCS #7 data object. [RFC3851]

Development of ubiquitous authentication. In each of the above-
mentioned proposals, several design elements are shared:

o The signature is carried S/MIME and OpenPGP has continued. While both have
achieved a significant user base neither has achieved ubiquity in the message header
deployment or use and does not affect their goals differ from those of DKIM.

In principle the message body.

o The signature may include certain headers.

o There is a policy mechanism, either explicit S/MIME protocol can support semantics such as domain
level signatures or implicit, that
tells receivers when to expect a signature.

o Keys are self-created (it is not necessary to buy a certificate).

o Keys are make use of keys stored in the DNS (it is DNS. However the
currently deployed base does not necessary and modifying it to deploy a
separate key server).

The remarkable similarity of these architectural proposals strongly
suggests that this architecture should be the basis for ubiquitous
authentication. DKIM was produced by merging the two do so would
require extensive effort.

Unlike all four previous
proposals of DomainKeys and Identified Internet Mail. Significant
enhancements were then made from that base.

The approach taken by IETF email security initiatives, DKIM differs from previous approaches to
message signing in that:

o the message signature is written as
employs a message header field so key centric Public Key Infrastructure (PKI) as opposed to
one that
neither human recipients nor existing MUA (Mail User Agent)
software are confused by signature-related content appearing in
the message body,

o there is no dependency based on public and private key pairs being
issued by well-known, trusted a certificate authorities,

o there is no dependency on in the deployment style of any new Internet
protocols or services for public key distribution Kohnfelder (X.509)
or revocation,

o it makes no attempt to include encryption as part Zimmerman (web of trust). That is, the
mechanism.

1.2.2. What is owner of a key asserts its
validity, rather than relying on having a broader semantic
implication of the purpose assertion, such as a quality assessment of DKIM? the
key's owner/. DKIM lets treats quality assessment as an organization take responsibility for independent,
value-added service, beyond the initial work of deploying a message. The
organization taking responsibility is
validating signature service.

NOTE: It would be useful to include a handler citation to a general
discussion about PKI issues, including their long history of
difficulties with respect to the message,
either as its originator or as an intermediary. Their reputation Internet.

Further, DKIM's PKI is
the basis for evaluating whether supported as additional information records to trust
the message for delivery.

The owner existing Domain Name Service, rather than requiring deployment of the domain name being used for
a new query infrastructure. This approach also has significant
performance advantages as DNS is layers on UDP and key retrieval is
typically achieved in a single round trip.

2. The DKIM signature Value Proposition

Spam can be understood as two separate problems. The first is
declaring the
problem of the companies that they are accountable for the message. inappropriately aggressive, in
sending out unsolicited marketing email. This means that
their reputation accounts for, perhaps,
5% of the spam volume and is at stake.

By design, DKIM purposely:

o in any case usually handled by existing
spam filters. The second problem is compatible with rogue spam -- often involving
criminal activities -- mostly sent from coerced botnets of
compromised machines. For this latter set of mail, the existing origins of a
message are often falsely stated.

Even without the addition of independent accreditation services, DKIM
allows pair-wise sets of (possibly large) email infrastructure providers and
transparent spam
filtering companies to distinguish mail that is associated with a
known organization, from mail that might deceptively purport to have
the fullest extent possible

o requires minimal new infrastructure

o can be implemented independently of clients affiliation. This in order to reduce
deployment time
o does not require turn allows the use development of trusted third parties (e.g.,
certificate authorities) which might impose significant costs or
introduce delays 'whitelist'
schemes whereby authenticated mail from a known source with good
reputation is allowed to deployment

o can be deployed incrementally

o allows delegation bypass spam filters.

In effect the email receiver is using their set of signing known
relationships to third parties

o is not intended be used generate their own accreditation/reputation data.
This works particularly well for archival purposes

DKIM authentication provides one link in 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 chain stable set of responsibility,
hopefully leading organizations.

NOTE: Perhaps add some citations to better accountability by detailed discussions about spam
and phishing and the senders.

1.2.3. What does DKIM do? role of authentication and accreditation in
fighting them?

DKIM defines a mechanism by which email messages can be
cryptographically signed, permitting used in conjunction with a signing domain real-time blacklist allows phishing
emails to claim
responsibility for the introduction be preemptively blocked. The value of a message into cousin domain,
that could be mistaken for the mail
stream. The responsible organization adds a digital signature to legitimate domain, is significantly
reduced if the
message, associating it with a domain name number of emails that organization.
Typically, signing will can be done by an successfully sent from it
is small.

Phishing attacks are typically made against trusted brands, that is,
names that are closely affiliated with well-known organizations. A
DKIM-based accreditation service agent within the
authority of the message originator's Administrative Management
Domain (ADMD). (Signing might be performed can enforce a basic separation
between domains used by any of the functional
components in that environment, including such known organizations and domains used by
others.

Receivers who successfully validate a Mail User Agent (MUA), signature can use information
about the signer as part of a
Mail Submission Agent (MSA), program to limit spam, spoofing,
phishing, or an Internet Boundary MTA. other undesirable behavior, although the DKIM also
permits signing to be performed
specification itself does not prescribe any specific actions by authorized third-parties.)

1.2.4. Who validates the signature?

After
recipient.

3. DKIM's Goals

DKIM lets an organization take responsibility for a message has been signed, any agent in message. The
organization taking responsibility typically is a handler of the message transit
path
message, either as its originator or as an intermediary. It can choose also
be an independent service, providing assistance to validate the signature. Message recipients can
verify a handler of the signature by querying
message. Their reputation is the signer's domain directly basis for evaluating whether to
retrieve the appropriate public key, and thereby confirm that
trust the message was attested to by a party in possession of the private key for the signing domain. Typically, validation will be done by an
agent in the ADMD delivery.

The owner of the message recipient. Again, this may be done
by any functional component within domain name being used for a DKIM signature is
declaring that environment. (Notably this they are accountable for the message. This means that
their reputation is at stake.

By design, DKIM purposely:

o is compatible with the signature existing email infrastructure and
transparent to the fullest extent possible

o requires minimal new infrastructure

o can be used by the recipient ADMD's
filtering software, rather than requiring the recipient end-user implemented independently of clients in order to
make an assessment.)

1.2.5. What does DKIM *not* do?

DKIM does not: reduce
deployment time

o offer any assertions about does not require the behaviors use of the identity doing the
signing.

o prescribe any specific actions for receivers trusted third parties (e.g.,
certificate authorities) which might impose significant costs or
introduce delays to take upon
successful (or unsuccessful) signature validation.

o provide protection after message delivery. deployment

o protect against re-sending (replay of) a message that already has
a valid signature; therefore a transit intermediary or a recipient can re-post the message be deployed incrementally

o allows delegation of signing to third parties

o is not intended be used for archival purposes

DKIM authentication provides one link in such a way that the signature would
remain valid, although the new recipient(s) would not have been
specified chain of responsibility,
hopefully leading to better accountability by the originator.

1.3. Outline Potential DKIM Applications

TBD

2. DKIM Within Existing Internet Email

2.1. Review of Internet Mail Service Architecture

Internet Mail has a simple split between senders.

3.1. Treat verification failure as if unsigned.

PGP and S/MIME were both designed for strong cryptographic
protection. This included treating validation failure as message
failure, at least warning the user world, in that the form message was unsigned. In
a small number of Mail User Agents (MUA), and cases the transmission world, in application went even further 'warning'
the form of user whenever a signed message was received. This approach has
proved problematic. Hence for DKIM, the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS guidance is responsible for accepting 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 message from one User
and delivering it digital
signature to one or more others, creating a virtual MUA-to-
MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and message unless doing so causes the final MTA is called the Mail Delivery
Agent (MDA)
+--------+
+---------------->| User |
| +--------+
| ^
+--------+ | +--------+ .
| User +--+--------->| User | .
+--------+ | +--------+ .
. | ^ .
. | +--------+ . .
. +-->| User | . .
. +--------+ . .
. ^ . .
. . . .
V . . .
+---+----------------+------+------+---+
| | | | | |
| +--------------->+ | | |
| | | | |
| +---------------------->+ | |
| | | |
| +----------------------------->+ |
| |
| Mail Handling Service (MHS) |
+--------------------------------------+

Figure 1: Basic Internet Mail Service Model

Modern Internet Mail service is marked by many independent operators,
many different components for providing users with service and many
other components for performing message transfer. Consequently, it
is necessary to distinguish administrative boundaries that surround
sets of functional components.

2.1.1. Administrative Actors

Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). Examples include an end-
user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured
into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with
other ADMDs.

Basic components of ADMD distinction include:

Edge: Independent transfer services, in networks at the edge of the
Internet Mail service.

User: End-user services. This might be subsumed under the Edge
service, such as is common for web-based email access.

Transit: These are Mail Service Providers (MSP) offering value-added
capabilities for Edge ADMDs, such as aggregation and filtering.

Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level.

+-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- |
| | +---------------------->| | | |
| User | | |-Edge--+--->|-User |
| | | | +--->| | | |
| V | | | +-------+ +-------+
| Edge--+---+ |
| | | +---------+ |
+-------+ | | ADMD2 | |
| | ----- | |
| | | |
+--->|-Transit-+---+
| |
+---------+

Figure 2: ADministrative Management Domains (ADMD) Example

The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for
concern over interaction and protection between independent
administrations. The interactions between functional components
within an ADMD are subject to the policies of that domain.

Common ADMD examples are:

Enterprise Service Providers:

Operating an organization's internal data and/or mail services.

Internet Service Providers:

Operating underlying data communication services that, in turn,
are used by one or more Relays and Users. It is not necessarily
their job to perform email functions, but they can, instead,
provide an environment in which those functions can be performed.

Mail Service Providers:

Operating email services, such as for end-users, or mailing lists.

2.1.2. Field Referencing Convention

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 and <RFC2821.MailFrom> is the address in the SMTP
"Mail From" command.

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
depend upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it.

2.2. Where to Place DKIM Functions

Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange, such as:

Outbound: MUA, MSA or boundary MTA.

Inbound: Boundary MTA, MDA or MUA.

By having an MUA do the signing or verifying, there is no dependence
upon implementation by an email service infrastructure. By having an
MHS component do signing or verifying, there is no dependence upon
user training or the upgrade of potentially large numbers of user
applications.

Perhaps 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 outermost portion of the MHS, true end-to-end service is
provided, requiring the smallest amount of trust on the rest of the
infrastructure. By signing or verifying at a boundary, the smallest
number of systems need modifying and the signature is subject to the
smallest amount of handling that can break the signature.

The choice of identity message to use might not be obvious. Examples
include:

Author The domain associated with the RFC2822.From field provides
basic authorization for the author to generate mail. Because the
organization controlling
treated more favorably than an unsigned one. Any messages that domain is closest carry
signatures that fail verification are thus much more likely to the author,
they well might be in the best position to offer their reputation
as a basis for asserting
genuine message that has been damaged in transit than an attempted
forgery. It makes no sense to warn the content recipient unless it is "safe".

Operator Email reputation services have long-used known
that the IP Address of sender always signs email messages and that there is a
client SMTP server as the basis for assessing whether to permit
relay or delivery of high
probability that a message. These Addresses identify forgery would be attempted.

3.2. Domain-level assurance

PGP and S/MIME apply the
operator end-to-end principle in terms of an individual
originators and recipients, notably using full email service, rather than necessarily indicating addresses. DKIM
seeks accountability at the author of messages being sent by that service. Use more coarse grain of an
operator's domain name is organization or,
perhaps, a natural extension of department. A deployed construct that enables this model.

Third-party An independent service might wish
granularity is the domain name, to certify an author, a
message or an operator, by providing which the signing key record is
bound.

3.3. Incremental adoption

DKIM can immediately provide benefit between any two organizations
that exchange email and implement DKIM. In the usual manner of
"network effects", the benefits of DKIM increase dramatically as its own signature
adoption increases.

Over time, DKIM adoption might become sufficiently widespread to
permit special, negative handling of messages that are not signed.
However early benefits do not require this more-stringent
enforcement.

3.4. Minimal infrastructure

DKIM can be implemented at a
message. Hence, evaluation variety of places within an
organization's email service. This permits the message will organization to
choose how much or how little they want DKIM to be based upon the
identity part of that third-party, their
infrastructure, rather than any part of a more localized operation.
Similarly, DKIM's reliance on the identities
involved in creation or transfer Domain Name Service greatly reduces
the amount of new administrative infrastructure that must be deployed
over the message. Indeed, this
model is already emerging among a number open Internet.

Even with use of reputation-vetting
services and the DNS, one challenge is similar that it is usually
operated by different administrative staff than those who operate an
organization's email service. In order to the way a credit card permits ensure that DKIM DNS
records are accurate, this imposes a
customer to make purchases, based upon requirement for careful
coordination between the reputation of two operations groups.

3.5. Transparent signature

S/MIME and PGP are both modify the
credit card company -- message body. Hence, their
presence is visible to all email recipients and its willingness their user software
must be able to issue the card.

Ultimately, process the choice of component associated constructs. In order to
facilitate incremental adoption, DKIM is designed to be transparent
for signing will depend upon both
the recipients that do not support it.

3.6. Security policy

DKIM is pursuing an incremental innovation, over basic identity being used and
authentication, through the tradeoff between flexibility publication of uses,
versus administrative and operational control. The choice security policies
associated with one or of
component for verification will depend upon the intended use and
similar concerns about flexibility and control. A typical choice identities presented in a message. For
example, a valid DKIM signature allows the signing party to assert
responsibility for
reputation-related verification will be a message . For a recipient to place the signature
verification function "close" interpret an
unsigned message it is necessary to the message-filtering engine.

2.3. Impact on Email Activities

2.3.1. Resources

Although the cryptographic authentication are considered know whether it should expect a
message from that source to be
computationally expensive, signed and if so the real impact of signature
characteristics to expect. It would, therefore, be helpful for a mechanism, like DKIM,
is remarkably small. Direct impact on CPU-load has been measured
potential signer to be 10-15%. Usually, email able to publish whether they sign all of their
message. Once this is i/o-intensive, published, recipients can choose to handle the
receipt of unsigned messages with unused
computational capacity. So, added caution.

4. A Quick Overview of DKIM

DKIM has a very constrained set of capabilities, primarily targeting
email while it is likely that no new hardware will in transit, from an originator to one or more
recipients. DKIM defines a mechanism by which email messages can be required.

2.3.2. Operations

Administrative cost
cryptographically signed, permitting a signing domain to deploy, versus expected reduction in claim
responsibility for the cost presence of administration for problem email.

Challenge a message in the mail stream. A
responsible organization adds a digital signature to the message,
associating it with a domain name 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 that organization. Typically,
signing component

2.3.3. Users

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.

Challenge will be done by a service agent within the authority of mailing lists. Different list styles warrant different
signature policies.

Can the
message originator's Administrative Management Domain (ADMD).
(Signing might be hidden from end-user; used performed by filter engine. Method and
benefits for displaying to users unknown.

2.4. Migrating from DomainKeys

2.4.1. Signing

2.4.1.1. DNS Records

DKIM is upward compatible with existing DomainKeys (DK) DNS records,
so any of the functional components in
that environment, including a Mail User Agent (MUA), a Mail
Submission Agent (MSA), or an Internet Boundary MTA. DKIM module does not automatically require additional DNS
administration! also
permits signing to be performed by authorized third-parties.)

4.1. What is a DKIM has enhanced signature?

A signature covers the DK DNS key record, to permit message body and selected header fields. The
signer computes a hash of the addition selected header fields and another hash
of several the body. They then use a private key to cryptographically encode
this information, along with other signing parameters.

2.4.1.2. Signing Module

DKIM uses The signature
information is placed into a different RFC2822 [RFC2822] new header field for storing of the
signature, in RFC2822
[RFC2822] message.

4.2. The Selector construct

In order to distinguish it from DK.

DKIM includes language allow a domain name to make it clear which support multiple, simultaneous
keys, a particular header field
is signed, if there signature is more than one identified by the combination of the
domain name and an added field, called the "selector". Both of these
are coded into the DKIM-Signature header field field. 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 given name in portion of the message.

DKIM allows some values that were scalars in DomainKeys namespace to a trusted third party.

Examples include: jun2005.eng._domainkey.example.com

widget.promotion._domainkey.example.com

NOTE: It is intended that assessments of DKIM identities be colon-
separated arrays. For example, based
on the list of query methods used to
find a key and domain name, rather than include the "t=" tags (originally testing, now flags).

DKIM selector. This
permits copying the original version of headers fields and their
values, selector to aid in diagnosing signatures that do not survive transit.

DKIM has be used only for key administration,
rather than having an effect on reputation assessment.

4.3. Who validates the ability to limit keys to hash algorithms specified in signature?

After a
list, message has been signed, any agent in the DNS record.

DKIM allows body length limits, to permit signatures, to survive message transit through some intermediaries, such as some mailing list agents
that add text
path can choose to validate the end signature. Validation of the message.

2.4.1.3. Boundary MTA

Enforce signature policies and practises

2.4.2. Verifying

2.4.2.1. DNS Client

2.4.2.2. Verifying module

See "Signing Module".

2.4.2.3. Boundary MTA

Strip "local" signatures
signature, by a later agent in the path, demonstrates that are not local?

2.5. { Misc Text -- Should go elsewhere, if used at all }

DKIM permits the
signing identity to be different from the identities
used took responsibility for the author or message

Message recipients can verify the initial posting agent. This is essential,
for example, to enable support of signing signature by authorized third-
parties, querying the signer's
domain directly to retrieve the appropriate public key, and thereby
confirm that the message was attested to permit signatures by email providers who are
otherwise independent a party in possession of
the domain name private key for the signing domain. Typically, validation will
be done by an agent in the ADMD of the message author. 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 permits restricting NOT do?

DKIM does not:

o offer any assertions about the use of a signature key to particular
types behaviors of services, such as only the identity doing the
signing.

o prescribe any specific actions for email. This is helpful when
delegating signing authority, such as receivers to take upon
successful (or unsuccessful) signature validation.

o provide protection after message delivery.

o protect against re-sending (replay of) a particular department message that already has
a valid signature; therefore a transit intermediary or
to a third-party outsourcing service.

With DKIM the signer MUST explicitly list recipient
can re-post the headers message in such a way that are
signed. This is an improvement because it requires the signer to use signature would
remain valid, although the more conservative (likely to verify correctly) mechanism and
makes it considerably more robust against new recipient(s) would not have been
specified by the handling of
intermediary MTAs. originator.

4.5. Does DKIM self-signs the DKIM-Signature header field, eliminate anonymity for email?

The ability to protect against send a message that does not identify its being modified.

In order author is
considered to survive the vagaries be a valuable quality of different the current email transfer systems,
mechanisms like system. It
turns out that DKIM must evaluate the message data in some canonical
form, such as treating is particularly helpful to this goal, because a string
DKIM signature will typically be used to identity an email system
operator, rather than a content author. Knowing that a mail
definitely came from example.com does not threaten the anonymity of spaces as tabs as
the user, if they were it is still possible to obtain effectively anonymous
accounts at example.com and other web mail providers.

4.6. Outline potential DKIM applications

TBD

4.7. What is a
single space. DKIM has added the "relaxed" canonicalization in place
of "nofws".

3. policy?

TBD

5. DKIM Within Existing Internet Email

3.1.

5.1. Review of Internet Mail Service Architecture

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
the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User
and delivering it to one or more others, creating a virtual MUA-to-
MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and the final MTA is called the Mail Delivery
Agent (MDA)

+--------+
+---------------->| User |
| +--------+
| ^
+--------+ | +--------+ .
| User +--+--------->| User | .
+--------+ | +--------+ .
. | ^ .
. | +--------+ . .
. +-->| User | . .
. +--------+ . .
. ^ . .
. . . .
V . . .
+---+----------------+------+------+---+
| . . . . |
| +...............>+ . . |
| . . . |
| +--------------->+ | | |
| | | | |
| +---------------------->+ | |
| +......................>+ . |
| . . |
| +----------------------------->+ +.............................>+ |
| |
| Mail Handling Service (MHS) |
+--------------------------------------+

Figure 3: 1: Basic Internet Mail Service Model

3.1.1.

5.1.1. Administrative Actors

Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust.. Examples include an end-
user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured
into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with
other ADMDs.

Basic components of ADMD distinction include:

Edge:

Edge -- Independent transfer services, in networks at the edge
of the Internet Mail service.

User:

User -- End-user services. These might be subsumed under an
Edge service, such as is common for web-based email access.

Transit:

Transit -- These are Mail Service Providers (MSP) offering
value-added capabilities for Edge ADMDs, such as aggregation
and filtering.

Figure 4: 2: ADministrative Management Domains (ADMD) Example

Common ADMD examples are:

Enterprise Service Providers: Providers -- Operating an organization's
internal data and/or mail services.

Internet Service Providers: Providers -- Operating underlying data
communication services that, in turn, are used by one or more
Relays and Users. It is not necessarily their job to perform
email functions, but they can, instead, provide an environment
in which those functions can be performed.

Mail Service Providers: Providers -- Operating email services, such as for
end-users, or mailing lists.

3.1.2.

5.1.2. Field Referencing Convention

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. The choices
of what Deciding
which ADMD to have shall perform signing or verifying, which identity to
assign and which functional components to use for DKIM processing
depend upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it.

3.2. Where to Place DKIM Functions

Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange, such as:

Outbound: arrange. Examples include:

Outbound -- MUA, MSA or boundary MTA.

Inbound:

Inbound -- Boundary MTA, MDA or MUA.

By having an MUA do the signing or verifying, there is no dependence
upon implementation by an email service infrastructure. By having
and an
MHS component do signing or verifying, there is no dependence upon
user training or the upgrade of potentially large numbers of user
applications.

Perhaps

For implementation by an ADMD's email service operators, perhaps 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
MSA and MDA, respectively, this outermost portion of the MHS provides
true end-to-end service, and requires the smallest amount of trust of
the intervening service infrastructure. By signing or verifying at a
boundary, the smallest number of systems need modifying within an
ADMD and the signature is subject to the smallest amount of handling
that can break the signature. Note, however, that this will
eliminate DKIM signing for mail that stays within the ADMD.

The choice of identity to use might not be obvious. Examples
include:

Author -- The domain associated with the RFC2822.From field
provides basic authorization for the author to generate mail.
Because the organization controlling that domain is closest to
the author, they well might be in the most obvious choices within best position to offer
their reputation as a basis for asserting that the MHS are content is
"safe".

Operator -- Email recipient services have long-used the MSA or MDA,
and IP
Address of a client SMTP server as the outbound or inbound (boundary) MTA. By signing basis for assessing
whether to permit relay or verifying
at delivery of a message. These
Addresses identify the outermost portion operator of an email service, rather
than necessarily indicating the MHS, true end-to-end service author of messages being sent
by that service. Use of an operator's domain name is
provided, requiring the smallest amount a natural
extension of trust on this model.

Third-party -- An independent service might wish to certify an
author, a message or an operator, by providing its own
signature to a message. Hence, evaluation of the message will
be based upon the rest identity of that third-party, rather than any
of the
infrastructure. By signing identities involved in creating or verifying at a boundary, transferring the smallest
message. Indeed, this model is already emerging among a number
of systems need modifying reputation-vetting services and the signature is subject similar to the
smallest amount way a
credit card permits a customer to make purchases, based upon
the reputation of handling that can break the signature. credit card company -- and its
willingness to issue the card.

Ultimately, deciding where to sign a message is likely will depend upon both
the identity being used and tradeoffs among flexibility of uses,
administrative control, and operational control. Deciding where to
verify a message will depend upon the intended use and similar
concerns about flexibility and control. A typical choice for
reputation-related verification will be to place the signature
verification function "close" to depend upon
a combination of the identity being used, and tradeoffs between
flexibility, control, and administrative ease.

3.3. message-filtering engine.

5.3. Impact on Email Activities

3.3.1.

5.3.1. Resources

Although the cryptographic authentication are is considered to be
computationally expensive, the real impact of a mechanism, mechanism like DKIM, DKIM
is remarkably small. Direct impact on CPU-load has been measured to
be 10-15%. Usually, email is Mail handling tends to be, i/o-intensive, with so that
dedicated email platforms tend to have unused computational capacity. So, it
It is therefore likely that no new hardware will be required.

3.3.2. Operations

Administrative cost to deploy, versus expected reduction in the cost
of administration for problem email.

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

3.3.3. Users

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.

Challenge of mailing lists. Different list styles warrant different
signature policies.

Can be hidden from end-user; used by filter engine. Method and
benefits for displaying to users unknown.

3.4. Migrating from DomainKeys

3.4.1. Signing

3.4.1.1. DNS Records

DKIM is upward compatible with existing DomainKeys (DK) DNS records,
so that a DKIM module does not automatically require additional DNS
administration! DKIM has enhanced the DK DNS key record, to permit
the addition of several parameters.

3.4.1.2. Signing Module

DKIM uses a different RFC2822 [RFC2822] header field required for storing the
signature, in order to distinguish it from DK.

DKIM includes language to make it clear which particular header field
is signed, if there is more than one header field of a given name in
the message.

DKIM allows some values that were scalars in DomainKeys
these systems to be colon-
separated arrays. For example, the list of query methods used able to
find a key and the "t=" tags (originally testing, now flags). add DKIM permits copying the original version of headers fields and their
values, support.

5.3.2. Operations

The costs to aid in diagnosing signatures that do not survive transit. deploy, administer and operate DKIM has vary greatly,
depending upon the ability to limit keys to hash algorithms specified in a
list, in placement of DKIM-related modules. The greatest
flexibility comes from placing the DNS record.

DKIM allows body length limits, to permit signatures, to survive
transit through some intermediaries, such modules as some mailing list agents
that add text close as possible to
the end of user. However this also imposes the message.

3.4.1.3. Boundary MTA

Enforce signature policies and practises

3.4.2. Verifying

3.4.2.1. DNS Client

3.4.2.2. Verifying module

See "Signing Module".

3.4.2.3. greatest costs. The
most common scenarios are likely to be:

Boundary MTA

Strip "local" signatures that are not local?

3.5. { Misc Text -- Should go elsewhere, if used at all } Here, DKIM permits the signing identity to be different from the identities is used only for email external to the author or the initial posting agent. This
ADMD. Administration and operation is essential, the simplest, but could
cause problems for example, to enable support of signing by authorized third-
parties, and to permit signatures by email providers mobile users who are
otherwise associated with the
organization but must send mail using facilities that are
independent of their home ADMD. It also provides no assistance
for inter-departmental accountability within the domain name ADMD..

MSA/MDA (Department) -- Placing DKIM support at the points of
submission and delivery increases the message author.

DKIM permits restricting deployment costs but still
keeps control within the use ADMD's operational staff. It avoids the
considerable, added costs of a signature key having to particular
types enhance all of services, such as only for email. the MUAs.
This is helpful when
delegating signing authority, such as to a particular department or
to a third-party outsourcing service.

With DKIM does not improve the lot of mobile users who submit from
independent MSAs but does provide full protection within the signer MUST explicitly list ADMD.

MUA -- Obviously this can provide the headers that are
signed. This is an improvement because it requires most complete protection, but
at the signer cost of considerable added administrative effort. Worse,
there is extensive evidence that email infrastructure services
often perform changes to use message content that can break a message
signature. Examples include transformation by the more conservative (likely MSA to verify correctly) mechanism and
makes it considerably more robust against ensure
that the handling message is in full conformance with Internet standards
and transformation by Boundary MTAs, to ensure conformance with
organizational policies about external communications.

In spite of
intermediary MTAs. these concerns, placing DKIM self-signs support into the DKIM-Signature header field, MUA is
the only way to protect against ensure that a highly mobile user retains its being modified.

In order
benefits, in spite of having to survive the vagaries send mail through independent
MSAs.

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

5.3.3. Users

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.

Challenge of mailing lists. Different list styles warrant different email transfer systems,
mechanisms like
signature policies.

Can be hidden from end-user; used by filter engine. Method and
benefits for displaying to users unknown.

5.4. Migrating from DomainKeys

5.4.1. Signing

DNS Records: DKIM must evaluate the message data in some canonical
form, such as treating a string of spaces as tabs as if they were is upward compatible with existing DomainKeys
(DK) DNS records, so that a
single space. DKIM module does not automatically
require additional DNS administration! DKIM has added enhanced the "relaxed" canonicalization in place DK
DNS key record, to permit the addition of "nofws".

4. several parameters.

Boundary MTA: Enforce signature policies and practices

5.4.2. Verifying

DNS Client: TBD

Verifying module: See "Signing Module".

5.4.3. Boundary MTA

Strip "local" signatures that are not local?

6. DKIM Service Architecture

DKIM provides an end-to-end service for signing and verifying
messages that are in transit. It is divided into components that can
be performed using different, external services, such as for key
retrieval, although the basic DKIM operation provides an initial set.

|
| - RFC2822 Message
V
+---------------------------------------------+
+-----------+ | ORIGINATING OR RELAYING ADMD |
| | | ============================ |
| Signer | | |
| Practises Practices +......>| SIGN MESSAGE |
| | | ...> ADD A SIGNATURE HEADER FIELD |
+-----+-----+ .....>| . GET (Domain, Selector, Priv-Key) |
. . | ... COMPUTE SIGNATURE |
. V +----------------+----------------------------+
. +-------+ | - Message
. | | | 1*(Domain, Selector,
. | Key | | Sig)
. | Store | [Internet]
. | | |
. +---+---+ V
. . +---------------------------------------------+
. . | RELAYING OR DELIVERING ADMD |
. . | =========================== |
. . | |
. . | VERIFY MESSAGE (Verifier Practises) Practices) |
. . | ...> VERIFY A SIGNATURE HEADER FIELD |
. . | . GET A SIGNATURE |
. .....>| . LOOKUP PUB-KEY (Domain, Selector) |
. | . VERIFY SIGNATURE VALUE |
. | ... EVALUATE SIGNATURE CONSTRAINTS |
. +-------------------+-------------------------+
. | - Verified Domain(s)
. V - [Report]
. +---------------------------------------------+
. | |
. | MESSAGE DISPOSITION |
.............>| SIGNER PRACTICES |
.............>| REPUTATION |
. | |
+-----+------+ +---------------------------------------------+
| |
| Reputation |
| |
+------------+>

Figure 5: DKIM Service Architecture

Basic message process divides between signing the message, validating
the signature, and the performing further decision-making based upon
the validated signature. The component doing the signing applies
whatever signing policies are in force, including ones that determine
what private key to use. Validation may be performed by any
functional component along the relay and delivery path. The public
key is retrieved, based upon the parameters strored in the message.
The example shows use of the validated identity for assessing an
associated reputation. However it could be applied for other tasks,
such as management tracking of mail.

5. Relationship to previous Message Signature Technologies

DKIM is the fifth IETF proposal for an email signature scheme. The
first RFC describing Privacy Enhanced Mail (PEM) was published in
1987 [RFC0989]. The PEM scheme went through a number of revisions
and eventually transformed into MIME Object Security Services in 1995
[RFC1848].

Neither PEM nor MOSS ever achieved significant deployment. PEM
relied on the prior deployment of an extensive PKI predicated on a
rigid hierarchy of Certificate Authorities. By the time it was
understood that this infrastructure assumption was unrealistic the
opportunity to deploy PEM had closed.

Pretty Good Privacy (PGP) was developed by Phil Zimmerman and
released in 1991 and quickly established a significant support base
within the security community. This support base was driven by two
principal factors: superior ease of deployment and an aggressive
marketing campaign assisted by

Figure 3: DKIM Service Architecture

Basic message processing divides between signing the U.S. government. A working group
was formed within message,
validating the IETF to continue development of signature, and then performing further decision-making
based upon the PGP
protocol as OpenPGP beginning with publication of validated signature. The component doing the original
protocol as an informational RFC signing
applies whatever signing policies are in 1996 [RFC1991].

At the same time RSA Security, the holder of the patent rights force, including ones that
determine what private key to use. Validation may be performed by
any functional component along the
principle relay and delivery path. The
public key cryptography algorithm independently developed
Secure MIME (S/MIME) which employed is retrieved, based upon the recently developed MIME
format to transport a PKCS #7 data object. S/MIME was particularly
attractive for software developers who had already implemented SSL as
much parameters stored in the
message. The example shows use of the code required to support validated identity for
assessing an associated reputation. However it could be reused. applied for
other tasks, such as management tracking of mail.

7. Implementation Considerations

7.1. Development

7.1.1. Coding Criteria for Cryptographic Applications

Correct implementation of S/MIME and OpenPGP has continued in the IETF since.
While both have achieved a significant user base neither has achieved
ubiquity. In particular it cryptographic algorithm is notable that only a small percentage necessary
but not a sufficient condition for coding of messages on the IETF mailing lists concerned with cryptographic
applications. Coding of cryptographic libraries requires close
attention to security considerations that are
signed.

5.1. Transparent Signature

The core goals unique to cryptographic
applications.

In addition to the usual security coding considerations, such as
avoiding buffer or integer overflow and underflow, implementers
should pay close attention to management of DKIM require cryptographic private
keys and session keys, ensuring that use of message signatures becomes
ubiquitous. For this these are correctly initialized
and disposed of.

Operating system mechanisms that permit the confidentiality of
private keys to be possible it must protected against other processes SHOULD be possible used
when available. In particular, great care MUST be taken when
releasing memory pages to apply a
signature the operating system to any message in any circumstance with a negligible chance ensure that private
key information is not disclosed to other processes.

On multiple processor and dual core architectures, certain
implementations of causing public key algorithms such as RSA may be
vulnerable to a negative user experience timing analysis attack.

Support for any recipient regardless of
the legacy email client used.

Experiences from S/MIME and PGP deployment cryptographic hardware providing key management
capabilities is strongly indicate that
this usability goal can only be met if the encouraged. In addition to offering
performance benefits, many cryptographic hardware devices provide
robust and verifiable management of the signature
leaves the message body unchanged.

S/MIME private keys.

Fortunately appropriately designed and PGP coded cryptographic libraries
are both designed to achieve the highest level available for most operating system platforms under license terms
compatible with commercial, open source and free software license
terms. Use of
security possible. The sender standard cryptographic libraries is strongly
encouraged. These have been extensively tested, reduce development
time and support a wide range of cryptographic hardware.

7.1.1.1. Signer

Signer implementations SHOULD provide a message is assured that the
confidentiality and/or integrity convenient means of the message are protected from
the originating end point machine
generating DNS key records corresponding to the destination end point.

Achieving this level signer configuration.
Support for automatic insertion of security naturally places requirements on
both key records into the sender and DNS is also
highly desirable. If supported however such mechanism(s) MUST be
properly authenticated.

Means of verifying that the signer configuration is compatible with
the receiver. Support for both signature and
encryption causes policy is also highly desirable.

Disclosure of a subtle but important architectural assumption to
be introduced. Although private signature and encryption are complimentary
from a cryptographic point of view their effect is entirely different
from key component to a messaging protocol point third party
allows that third party to impersonate the sender. Protection of view. A digital
private signature key data is
meta-data therefore a critical concern. Signers
SHOULD support use of cryptographic hardware providing information about key management
features.

The import and export of private keys, and the message contents.
Encryption is ability to generate a transformation of
CSR for certificate registration are highly desirable.

7.1.1.2. Verifier

Verifiers SHOULD treat the message content (and possibly
related meta-data).

The recipient result of the verification step as an encrypted email
input to the message must evaluation process rather than as providing a matter of
course have
final decision. The knowledge that a specially adapted email client capable message is authentically sent
by a domain does not say much about the legitimacy of decrypting the message. Adding a signature to message
unless the characteristics of the domain claiming responsibility are
known.

In particular, verifiers SHOULD NOT automatically assume that a email
message that does not in principle
create contain a requirement for the recipient to have signature or which contains a specially adapted
client provided the
signature that does not validate is added in forged. Verifiers should treat a manner
signature that fails to validate as if no signature was present.

7.1.2. Email Handlers

7.1.2.1. Mail User Agent

DKIM is ignored by
legacy clients.

In designed to support deployment and use in email components
other than an MUA. However an MUA may also however implement DKIM
features directly.

Outbound: If an MUA is configured to send email directly, rather
than relayed through an outbound MTA, the case of MUA SHOULD be considered
as if it were an S/MIME signature outbound MTA for the recipient purposes of DKIM. An MUA
MAY support signing even if mail is at a minimum
expected to have a client capable of decoding the MIME multipart/
security format. be relayed through an
outbound MTA. In practice this means that case the recipient must
support S/MIME. OpenPGP allows signature applied by the use 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 encapsulation
verification that is not MIME based. This has took place at some point in the advantage that inbound MTA
path. An MUA MAY perform DKIM signature verification directly.
Such an MUA SHOULD allow for the message can
be read using a standard email client. The disadvantage with this
approach case where mail is that the application of modified in
the signature inbound MTA path.

7.1.3. Mail Transfer Agent

It is visible to expected that the
user and thus intrusive.

5.2. Treat verification failure as if unsigned.

PGP and S/MIME were both designed to meet most common venue for a high standard DKIM implementation
with be a department or a boundary MTA.

Outbound: An Outbound MTA should allow for automatic verification
of
cryptographic excellence. At the time MTA configuration such that the protocols were designed MTA can generate an
operator alert if it
was generally considered determines that the correct thing for it is (1) an application edge MTA, (2)
configured to send email messages that do in not comply with the case of a signature verification failure was
published DKIM sending policy.

An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to warn the
user take steps necessary
to ensure that the message was unsigned. In a small number of cases the
application went even further 'warning' the user whenever a signed
message was received.

This type of user experience has since been severely deprecated. A
user who sent is constantly bombarded in compliance with warning the
advertised email sending policy.

Inbound: An inbound that does not support DKIM, it should avoid
modifying messages is much less
likely in ways that prevent verification by other
MTAs, or MUAs to respond appropriately when an important warning which the message may be forwarded.

Intermediaries: An email intermediary is
received.

While modern messaging infrastructure is considerably friendlier to
the use both an inbound and
outbound MTA. Each of digital signatures than the requirements outlined in the past even sections
relating to MTAs apply. If the intermediary modifies a residual
failure rate of 1% results message in unacceptably high support costs when
signatures are used ubiquitously.

It is now generally accepted
a way that breaks the correct semantics for an email signature verifier to adopt are to treat messages with the intermediary it SHOULD

* deploy abuse filtering measures on the inbound mail

* remove all signatures that fail as if they are unsigned.

It is highly unlikely that an attacker is going to add a digital
signature to a message unless doing so causes will be broken

In addition the intermediary MAY:

* Verify the message signature prior to be
treated more favorably than modification

* Incorporate an unsigned one. Any messages that carry
signatures that fail Authentication-Results header to report the
verification are thus much more likely result.

* Sign the modified message including the Authentication-Results
header

7.2. Filtering

Developers of filtering schemes designed to accept DKIM
authentication results as input should be a
genuine message aware that has been damaged in transit than an attempted
forgery. It makes no sense their
implementations will be subject to warn the recipient unless it is known
that the sender always signs counter-attack by email messages and that there is a high
probability that a forgery would be attempted.

5.3. Legacy Client Semantics abusers.
The deployed base efficacy of S/MIME is both a benefit and a burden. While
the S/MIME protocol is in principle capable of extension filtering scheme cannot therefore be determined by
reference to support
many of the features of DKIM, static test vectors alone; resistance to counter attack
must also be considered.

Naive learning algorithms that only consider the same is not true presence or absence
of the deployed
S/MIME base.

While the S/MIME protocol can a valid DKIM signature are vulnerable to an attack in principle support semantics such as
domain level signatures which a
spammer or make use other malefactor signs all their mail, thus creating a
large negative value for presence of keys stored a DKIM signature in the DNS the
legacy deployed base does not. The behavior hope of legacy clients
receiving an S/MIME message dependent
discouraging widespread use.

If heuristic algorithms are employed they should be trained on
feature sets that sufficiently reveal the novel semantics is
likely to result in a negative user experience in a significant
number internal structure of cases.

5.4. Key Centric PKI

Unlike all four previous IETF email security initiatives, the
DKIM
employs a key centric, directory based PKI as opposed responses. In particular the algorithm should consider the
domains purporting to a
certificate based PKI in claim responsibility for the style signature rather
than the existence of Kohnfelder (X.509) a signature or Zimmerman
(web not.

Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of trust).

While message syntax and PKI a DKIM signature SHOULD be
ignored.

7.3. DNS Server

TBD

7.4. Accreditation service

TBD

8. Deployment

This section describes the basic steps for introducing DKIM into an
organization's email service operation. The considerations are orthogonal in principle,
implementation practice means
divided between an organization's generating DKIM signatures
(Signing) and an organization's processing of messages that most S/MIME clients contain a
DKIM signature (Verifying).

8.1. Signing

Creating messages that have DKIM signatures requires modification of
only support
use two portions of keys contained in X.509/PKIX digital certificates.

Although PGP is sometimes held up as an alternative to a certificate
based PKI a PGP key signing is in essence a digital certificate by
another name. There has since been considerable conversion as X.509
has adopted the web email service:

o Addition of relevant DNS information.

o Addition of trust principle under the term cross-
certification. signature by a trusted module within the
organization's email handling service.

The signing module uses the appropriate private key, for creating a
signature. The chief distinction between means by which the PGP and PKIX models signing module obtains this key is
not specified by DKIM. Given that in the PGP model every user DKIM is also (potentially) a trust
provider. In PKIX trust providers are distinct from end-entities.

The Kohnfelder architecture was originally designed to allow intended for use of
public key cryptography before the ubiquitous availability of
networking. A particular benefit of the Kohnfelder architecture during
email transit, rather than for long-term storage, it is expected that Alice can send an encrypted message
keys will be changed regularly. Clearly this means that key
information should not be hard-coded into software.

8.1.1. DNS Records

A receiver attempting to Bob when validate a DKIM signature must obtain the only
transport available
public key that is sending floppy disks through the postal
system. Another benefit of associated with the Kohnfelder architecture is signature for that a
signed message.
The DKIM-Signature header in the message supported by a digital certificate is self supporting will specify the basic
domain name doing the signing and may the selector to be verified years after used for the fact provided only
specific public key. Hence, the relevant
<selector>._domainkeys.<domain-name> DNS record needs to contain a
DKIM-related RR that provides the CA
signing public key does not become compromised. information.

The principle weakness in PKIs based on the Kohnfelder architecture
is the difficulty administrator of locating the correct digital key zone containing the relevant domain name
adds this information. DNS administrative software varies
considerably in its abilities to add new (types of) DNS records.
Initial DKIM DNS information is contained within TXT RRs.

8.1.2. Signing Module

The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain (ADMD).
Common choices are expected to be department-level posting and
delivering agents, as well as boundary MTAs to the absence
of a directory infrastructure. This led Brian LaMacchia, then at MIT open Internet.
However, note that it is entirely acceptable to develop have signing and
validation be done by MUAs. Hence the MIT PGP key server, in effect returning to choice among the
original public key directory model proposed by Whitt Diffe modules
depends upon software development and Marty
Hellman.

XML Key Management Service (XKMS) realizes the key centric PKI model
as a SOAP based Web Service. In administrative overhead
tradeoffs. One perspective that helps resolve this choice is the XKMS model
difference between the PKI client makes
a request flexibility of use by systems at, or close to,
the form 'provide me with MUA, versus the signing key centralized control that Alice
uses with the PGP protocol'.

Although DKIM follows the same architectural model as XKMS, DNS is
used as more easily obtained
by implementing the transport layer in place of SOAP over HTTP.

The use of DNS significantly reduces mechanism "deeper" into the infrastructure requirements
for DKIM organization's email
infrastructure, such as existing DNS servers are used at its boundary MTA.

8.1.3. Signing Policies and Practices

Every organization (ADMD) will have its own policies and practices
for key distribution. This
approach also has significant performance advantages as DNS is layers
on UDP deciding when to sign messages and with what domain name and key retrieval is typically achieved in a single round
trip. XKMS requires a TCP session to be established
(selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the request
and response messages are significantly larger.

The principle disadvantage of using DNS over XKMS is likelihood that the DNS is
a network administration resource designed to answer questions about
current network configuration. While signing
practices will change over time, it is quite possible will useful to re-use have these
decisions represented in some sort of configuration information,
rather than being more deeply coded into the DNS infrastructure to support queries about past and even future
network configurations this signing software.

8.2. Verifying

Verification is not performed within an ADMD that wishes to make
assessments based upon the core objective of domain name used for a DKIM signature.
Any component within the
infrastructure. The DNS is thus unsuited to supporting any use of
digital signatures ADMD that handles messages, whether in which long term archival is desirable
transit or being delivered, can be appropriate to do the
possibility of repudiation is undesirable.

5.5. Domain Level Assurance

As previously mentioned PGP and S/MIME were designed in verifying.
It must communicate the heyday results of verification to another component
within the security end-to-end principle. It has since been realized ADMD that performs the end points with respect to trust are not desired 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 end
points Boundary MTA and assessment
performed by the MDA.

As with respect to the communication protocol.

When Alice sends a personal message signing process, choice of service venues for
verification and assessment -- such as filtering or presentation to Bob it is Alice the person,
not
the machine Alice happens to be using that recipient user -- depend on trade-offs for flexibility, control,
and operational ease. An added concern is that the true trust end
point. When Alice sends linkage between
verification and assessment entails essential trust: The assessment
module must have a piece of business correspondence to Bob it strong basis for believing that the verification
information is her employer. correct.

8.2.1. DNS Client

The objective 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 an concern.

8.2.2. Boundary Enforcement

In order for an assessment module to allow parties trust the information it
receives about verification, it is essential to accept responsibility
for messages by signing them. While accepting responsibility at eliminate
verification information originating from outside the
personal level may be desirable ADMD in some circumstances which
the Internet
now has a billion users. Attempting to achieve accountability in assessment mechanism operates. As a
population matter of a billion users friendly practice,
it is impractical, particularly when the
owner of equally important to make sure that verification information,
from within the domain example.com has ADMD, not escape out side of it.

In most environments, the ability easiest way to create a
practically unlimited number of accounts within that domain at will.

The logical unit enforce this stripping of accountability for DKIM
verification information is therefore the DNS
domain name to which place modules in the signing key record is bound receiving and not the
individual email user.

5.6. Security Policy
sending Boundary MTA(s). For incoming mail, check for known means of
communicating verification information and remove it. The innovation in DKIM same
applies for outgoing mail.

8.3. Transition strategy

Deployment of a new signature algorithm without a 'flag day' requires
a transition strategy such that has no precedent signers and verifiers can phase in
support for the previous email
security standards is new algorithm independently and if necessary phase
out support for the publication of a security policy. The
purpose of old algorithm independently.

DKIM is to allow achieves these requirements through two features. First a party to accept responsibility for an
email
signed message may contain multiple signatures created by the same
signer. Secondly the security policy layer allows the signing it. A message with
algorithms in use to be advertised, thus preventing a signature downgrade
attack.

8.3.1. Signer transition strategy

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
algorithm without disruption of service to legacy verifiers is treated as if
follows:

1. Signer signs with algorithm A

A. Signer advertises that it is unsigned. For a recipient to interpret an unsigned
message signs with algorithm A

2. Signer signs messages twice, first with algorithm A and algorithm
B

A. The signer tests new signing configuration

B. Signer advertises that it signs with algorithm A and
algorithm B

3. Signer determines that support for Algorithm A is no longer
necessary to know whether it should expect a message
from

4. Signer determines that source support for algorithm A it to be signed and if so the withdrawn

A. Signer removes advertisement for Algorithm A

B. Signer waits for cached copies of earlier signature characteristics policy to expect.
expire

C. Signer stops signing with Algorithm A

8.3.2. Verifier transition strategy

The introduction actions of security policy allows unsigned messages the verifier are independent of the signer's actions
and
messages that fail signature validation do not need to be subjected to a higher
level of anti-spam filtering or rejected out of hand performed in circumstances
where the owner of the purported originating domain suggests. For
example a bank concerned at the possibility of phishing attack might
publish particular sequence. The
verifier may make a policy stating that all legitimate messages from the domain
are signed.

While the Sender-ID/SPF security policy format allows application to
existing formats including PGP and S/MIME the advantages decision to
developing the protocol and security policy in tandem are
considerable. It is not practical cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be
upgraded to expect support algorithm B without requiring algorithm B to be able to write a
useful sender signing policy for S/MIME or PGP within the constraints
withdrawn. The decisions of the 512 byte response message size imposed on the legacy DNS.

6. Implementation Considerations

6.1. Development

What software has to change, to use DKIM?

6.1.1. Signer verifier must make are therefore:

o The signer needs to add code in verifier MAY change the appropriate agent, to perform
signing, and they need to modify their DNS administrative tools to
permit creation degree of confidence associated with
any signature at any time, including determining that a given
signature algorithm provides a limited assurance of DKIM authenticity
at a given key records.

6.1.2. Validator strength.

* A validator needs to add code verifier MAY chose to the appropriate agent and then feed
the result into the portion evaluate signature records in any order
it chooses, including making use of their system needing it, such as a
filtering engine. the signature algorithm for
this purpose.

o The mere existence of verifier MAY make a valid signature determination that Algorithm A does not imply
offer a useful level of security, that the mail
is acceptable, such as for delivery. Acceptability requires an
assessment phase. Hence the result cost of verifying the
signature validation must be
fed into a vetting mechanism that is part less than the value of doing so.

* In this case the validator's filter.

6.1.3. Outbound mail user agent

TBD

6.1.4. Outbound mail transport agent

TBD

6.1.5. DNS Server

TBD

6.1.6. Mailing list manager

TBD

6.1.7. Inbound mail transport agent

TBD

6.1.8. Inbound mail user agent

TBD

6.1.9. Accreditation service

TBD

6.2. Deployment

6.2.1. Signing

6.2.1.1. DNS Records

add sig key info

6.2.1.2. Signing Module

Delete old signs with same key; add new sig

6.2.1.3. Boundary MTA

Enforce signature policies verifier ignores signatures created using the
algorithm A and practises

6.2.2. Verifying

6.2.2.1. DNS Client

Ensure able references to obtain DKIM key sig algorithm A in policy records

6.2.2.2. Verifying module

Validate sig; channel info to filtering engine. Maybe provide user-
visible info.

6.2.2.3. Boundary MTA

Strip "local" signatures that are
treated as if the algorithm is not local?

6.3. implemented.

o The verifier MAY decide to add support for additional signature
algorithms at any time.

* The verified MAY add support for algorithm B at any time.

9. Operations

6.3.1.

This section describes the basic steps for the continued operation of
email systems that use DKIM. This section discusses keeping DKIM
going, as opposed to getting DKIM started. The primary
considerations are: the upkeep of the selector files, and the
security of the private keys.

9.1. DNS Signature Record Deployment Considerations

TBD

6.3.2. Thoughts on Expiring Signatures

TBD

6.3.3.

The key point to remember is that the DNS Policy Record Deployment Considerations

TBD

6.3.4. Subdomain Considerations

TBD

6.3.5. Third DKIM selectors WILL and
SHOULD be changed over time. Some reasons for changing DKIM
selectors are well understood; others are still theoretical. There
are several schemes that may be used to determine the policies for
changing DKIM selectors:

o time based

o associations with clusters of servers

o the use of third party Signature Delegations

TBD

7. Outline Future Extensions signers

o security considerations

9.1.1. Time Basis and Security Considerations

The design 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 unapologetically focused 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.)

For example,

o Selectors should be changed more frequently on overcoming 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 need
for immediate deployment and achieving ubiquitous use in the near
future. As 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 original design discussions have generally taken selector.

o Whenever there is either suspicion or evidence of the approach 'if compromise
of the system or the private keys, you should change the selector.

9.1.2. Server Clusters

TBD

9.1.3. Deploying New Selectors

A primary consideration in doubt leave it out'.

The need changing the selector is remembering to exclude consideration
change it. It needs to be a standard part of these features in the near term
is in no way intended to preclude their development at operational staff
Methods and Procedures for your systems.

When deploying a later date.
Nor is selector, it needs to be phased in:

1. generate the lack of new public / private key pair and create a specification describing selector
record with the use of DKIM public key in it

2. add the new selector record to your DNS

3. turn on signing with the new private key

4. optionally back up the old private key in a
different PKI infrastructure intended to indicate an intention to
develop similar capabilities within secure location

5. remove the DKIM framework at old private key from your servers

6. after a future
date.

DKIM is an example period of 'Design for Deployment'. The need to support
rapid deployment is time, remove the overriding priority. It has traditionally
been asserted that deployment of a flawed cryptographic protocol is old selector

The time an almost unacceptable risk, that bad security is worse than no
security. Experience demonstrates otherwise. Informing users that
email unused selector should be kept in the DNS system 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
dependent on the reason it's being changed. If the private key has
definitely 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 exposed, the starting point
for a new cryptographic infrastructure that eventually replaces
legacy systems including S/MIME and PGP. While this future is
certainly preferable corresponding selector should be removed
immediately. Otherwise, longer periods are allowable.

9.1.4. Subdomain Considerations

TBD

9.1.5. Third party Signature Delegations

Allowing third parties to sign email from your domain opens your
system security to never achieving ubiquitous deployment of
strong cryptographic include the security in of the Internet it would certainly take third party's systems.
At a long time minimum, you should not allow the third parties to re-invent this particular wheel. Moreover use the
deployment of 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 proposed DKIM enhancements would face political
opposition from exposure for any given private key, and minimizes the adherents to existing formats to
impact if any given private key were exposed.

9.1.6. Mailing List Management

[ Note: this section may be rendered
historical. controversial. ]

A likely outcome mailing list often provides facilities to its administrator to
manipulate parts of such a strategy is that the existing
two way standards stalemate between S/MIME and PGP would become a
three way stalemate.

Another possible future mail messages that are flowing through. The
desired goal is that DKIM provides messages flowing through the 'bootstrap' mailing list will
be verifiable by the recipient, which means that
enables ubiquitous use of legacy infrastructure including either the
deployed base of PGP and S/MIME capable email clients and mailing
list (or its MSA) must sign the message, or the mailing list must not
perform actions on the messages that will break existing business infrastructure of commercial Certificate
Authorities. Such a strategy would make use of DKIM in conjunction
with
signatures. To avoid breaking existing PKI standards such as PKIX and XKMS and leverage
features of PGP and S/MIME where appropriate.

7.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 signatures, a
certainty. The RSA 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 algorithm at best provides equivalent
security after it performs any
content transformations to an 80 bit symmetric cipher when used with a 1024 bit key
[cite]. Extending the key size message, such as adding a footer to 2048 bits improves
the cipher
strength to only 112 bit equivalence. Achieving 128 bit security
requires body, adding a minimum of 3072 bits. Achieving equivalent cipher
strength prefix to a 192 bit symmetric algorithm requires a prohibitive key
size.

The choice of cryptographic algorithm affects the body, modifying the subject
header, etc.

o If a mailing list does not add its own DKIM algorithm signature, it must not
modify any existing headers that are listed in
two important ways. First there is the difficulty an h= parameter of storing keys in
any existing DKIM-Signature headers, nor may it add any footer
content to the DNS. Secondly 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 problem headers or body in a way that will break verification
of handling larger
signatures. existing DKIM-Signature headers, it should remove any existing
DKIM-Signature headers.

10. Outline Future Extensions

The default DNS response packet limit of 512 bytes places an
effective upper bound design of 4096 bits on a DKIM key. In practice is unapologetically focused on overcoming the need
for packaging, meta-data immediate deployment and achieving ubiquitous use in the desirability of using DNSSEC to
sign near
future. As such, the record reduces original design discussions have generally
taken the upper bound to no more than 2048 bits. approach 'if in doubt, leave it out'.

The size need to exclude consideration of these features in the DKIM signature itself near term
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 as the signature must be Base 64 encoded.

7.2. Possible future signature algorithm choices

ECC cryptography offers no way intended to preclude their development at a means later date.
Nor is the lack of implementing public key
cryptography using a key size and signature size that are each only
twice specification describing the size use of DKIM with a
different PKI infrastructure intended to indicate an intention to
develop similar capabilities within the equivalent symmetric key algorithm.

While ECC offers clear technical advantages over algorithms based on
the difficulty on solving the discrete log problem in DKIM framework at a finite field
it future
date.

DKIM is not possible at this point an example of 'Design for Deployment'. The need to be confident support
rapid deployment has been the overriding priority. It has
traditionally been asserted that a means deployment of
applying ECC a flawed cryptographic
protocol is an almost unacceptable risk, and that bad security is consistent with the position on intellectual
property adopted by the DKIM working group
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 found.

The DSA signature algorithm based on the discrete log problem faces
the same key size limitations rectified
far more quickly than deployment of protocols such as RSA. Importantly IPSEC or DNSSEC
where caution has prevailed.

One possible future for the design of DKIM and DNSSEC however the signature size is much smaller, that it becomes the same
size as starting point
for ECC algorithms.

It is likely a new cryptographic infrastructure that DSA would have received greater attention during
the design of DSA if key sizes greater than 512 bits eventually replaces
legacy systems including S/MIME and use PGP. While this future is
certainly preferable to never achieving ubiquitous deployment of hash
functions stronger than SHA-1 had been supported at
strong cryptographic security in the time. In
March 2006 Internet, it would certainly
take a proposed revision of long time to re-invent this particular wheel. Moreover the DSA signature algorithm
answered these objections permitting larger key sizes and specifying
use
deployment of stronger hash functions including SHA-256 and SHA 512. While the advantages offered by DSA are not sufficient proposed DKIM enhancements would face political
opposition from the adherents to warrant an
immediate transition existing formats to the new algorithm at this late stage it is
highly probably that the algorithm will be employed by DNSSEC when
finally deployed.

7.3. Transition strategy

Deployment rendered
historical. A likely outcome of such a new signature algorithm without a 'flag day' requires
a transition strategy such is that signers and verifiers can phase in
support for the new algorithm independently and if necessary phase
out support for the old algorithm independently.

DKIM achieves these requirements through existing
two features. First way standards stalemate between S/MIME and PGP would become a
signed message may contain multiple signatures created by the same
signer. Secondly the security policy layer allows
three way stalemate.

Another possible future is that DKIM provides the signing
algorithms in 'bootstrap' that
enables ubiquitous use to be advertised, thus preventing a downgrade
attack.

7.3.1. Signer transition strategy

Let of the old signing algorithm be A, legacy infrastructure, including the new signing algorithm be B.
The sequence
deployed base of events by which a Signer may introduce PGP and S/MIME capable email clients and the
existing business infrastructure of commercial Certificate
Authorities. Such a new signing
algorithm without disruption strategy would make use of service to legacy verifiers is as
follows:

1. Signer signs with algorithm A

A. Signer advertises that it signs with algorithm A

2. Signer signs messages twice, first DKIM in conjunction
with algorithm A existing PKI standards such as PKIX and algorithm
B

A. The signer tests XKMS and leverage
features of PGP and S/MIME where appropriate.

10.1. Introducing a new signing configuration

B. Signer advertises that it signs with algorithm A and

Regardless of whether extension of the DKIM feature set is desirable,
the need to replace the signature algorithm B
3. Signer determines that support for Algorithm A is no longer
necessary

4. Signer determines that support for practically a
certainty. The RSA signature algorithm A it at best provides equivalent
security to be withdrawn

A. Signer removes advertisement for Algorithm A

B. Signer waits for cached copies 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 earlier signature policy 3072 bits. Achieving equivalent cipher
strength to
expire

C. Signer stops signing with Algorithm A

7.3.2. Verifier transition strategy a 192 bit symmetric algorithm requires a prohibitive key
size.

The actions choice of cryptographic algorithm affects the verifier are independent of DKIM algorithm in
two important ways. First there is the signer's actions
and do not need to be performed difficulty of storing keys in a particular sequence.
the DNS. Secondly there is the problem of handling larger
signatures.

The
verifier may make default DNS response packet limit of 512 bytes places an
effective upper bound of 4096 bits on a decision to cease accepting algorithm A without
first deploying support DKIM key. In practice the
need for algorithm B. Similarly a verifier may be
upgraded packaging, meta-data and the desirability of using DNSSEC to support algorithm B without requiring algorithm B
sign the record reduces the upper bound to be
withdrawn. no more than 2048 bits.

The decisions size of the verifier must make DKIM signature itself is a weaker constraint. Even
so, while 1024 and even 2048 bit signatures are therefore:

The verifier MAY change likely to be
acceptable in most implementations larger signature sizes may become
prohibitive, particularly since the degree of confidence associated with
any signature at any time, including determining that a given must be Base 64
encoded.

10.2. Possible future signature algorithm provides choices

ECC cryptography offers a limited assurance means of authenticity
at implementing public key
cryptography using a given key strength.

A. A verifier MAY chose to evaluate size and signature records in any
order it chooses, including making use size that are each only
twice the size of the signature
algorithm for this purpose.

The verifier MAY make equivalent symmetric key algorithm.

While ECC offers clear technical advantages over algorithms based on
the difficulty on solving the discrete log problem in a determination that Algorithm A does finite field,
it is not
offer possible at this point to be confident that a useful level means of security,
applying ECC has been found that is consistent with the cost position on
intellectual property adopted by the DKIM working group.

The DSA signature algorithm based on the discrete log problem faces
the same key size limitations as RSA. Importantly for the design of verifying
DKIM and DNSSEC however, the signature size is less than much smaller, the value same
size as for ECC algorithms.

It is likely that DSA would have received greater attention during
the design of doing so.

A. In this case DSA if key sizes greater than 512 bits and use of hash
functions stronger than SHA-1 had been supported at the verifier ignores signatures created using time. In
March 2006 a proposed revision of the DSA signature algorithm A
answered these objections permitting larger key sizes and references to algorithm A in policy records
are treated as if specifying
the algorithm is use of stronger hash functions (including SHA-256 and SHA 512).
While the advantages offered by DSA are not implemented.

The verifier MAY decide sufficient to add support for additional signature
algorithms at any time.

A. The verified MAY add support for warrant an
immediate transition to the new algorithm B at any time.

7.4. this late stage, it is
highly probably that the algorithm will be employed by DNSSEC when
finally deployed.

10.3. Linkage to Other PKIs

The principle limitations in DKIM are the lack of support for end-
user keying, the lack of support for long term verification of
signatures
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
support these features features, this approach would require substantial
modifications that entirely negate the advantage of employing an
existing infrastructure. The point of using DNS is to reuse the DNS
infrastructure, not necessarily the DNS protocol.

The preferred approach to addressing these limitations is to support
use of a PKI infrastructure designed to support these requirements
such as PKIX, PGP or XKMS.

7.5.

10.4. Trusted Third Party Assertions

A DKIM signature tells the signature verifier that the owner of a
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
email senders internally. Recipients of smaller volumes of messages
are likely to need to acquire reputation data from a third party. In
either case the use of reputation data is intrinsically limited to
email sender which senders that have established a prior history of sending
messages.

Another commonly used technique for evaluating email senders is
accreditation. Most spam sent today is sent by criminals to further
a scheme that is unambiguously illegal. Spam demonstrates an
Internet equivalent of Gresham's law: the bad spam drives out the
merely irritating, the outright criminal drives out the bad. A
message is highly unlikely to be spam if if: the email sender that can
demonstrate that it is a legitimate business 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 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]

7.6.

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 and 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]

7.7.

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
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
using XKMS by means of the q= attribute. The verifier may then
discover the corresponding XKMS service using the SRV mechanism as
set out in the XKMS specification.

7.8.

10.7. Verification in the Client

The DKIM specification is designed to support edge to edge
authentication. The specification neither supports nor prohibits
verification of DKIM signatures in the client. In particular the
specification does not attempt to define client semantics for
signatures or provide an exhaustive list of user interface security
considerations.

For client based verification to be practical practical, it is likely the that a
client needs to be capable of determining that it is able to receive
messages that do not get clobbered before coming to any conclusions
with respect to unsigned messages.

DKIM requires that all verifiers treat messages with signatures that
do not verify as if they are unsigned. If verification in the client
is to be acceptable to users users, it is also essential that successful
verification of a signature does not result in a less than satisfactory
user experience than compared to leaving the message unsigned.

7.9.

10.8. Per user signature

Although DKIM is designed to support domain level signatures 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 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
scenario, it is likely that additional requirements are necessary 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. As At a minimum minimum, a key registration protocol must be defined.

7.10.

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 and 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
an
and key distribution are conflated, an approach hat that is satisfactory
for message level encryption schemes such as PGP and S/MIME S/MIME, but less
satisfactory for transport layer encryption such as SSL.

7.11.

10.10. Reuse of Key Record

A number of proposals have been made which 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 spams, an occasional
failure may even be cause for satisfaction, 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) 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 was 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.

7.12.

10.11. Use of Policy Record

DKIM demonstrates the power of using the DNS to distribute security
policy information. It is not possible to achieve robust security
unless the parties to a conversation know the security capabilities
and expectations of the other.

Any party proposing re-use of the DKIM policy record should carefully
consider whether their needs would be better met by proposing a
flexible security policy architecture in the DKIM style rather than
proposing ad-hoc extensions and variations.

At a minimum any proposal for new security policy formats that make
use of the TXT record should employ a new policy prefix and ensure
that mislabeled and wild-carded policy records are not accidentally
misinterpreted.

11. Acknowledgements

TBD

12. { Misc Text -- Should go elsewhere, if used at all }

DKIM permits the signing identity to be different from the identities
used for the author or the initial posting agent. This is essential,
for example, to enable support of signing by authorized third-
parties, and to permit signatures by email providers who are
otherwise independent of the domain name of the message author.

DKIM permits restricting the use of a signature key to particular
types of services, such as only for email. This is helpful when
delegating signing authority, such as to a particular department or
to a third-party outsourcing service.

With DKIM the signer MUST explicitly list the headers that are
signed. This is an improvement because it requires the signer to use
the more conservative (likely to verify correctly) mechanism and
makes it considerably more robust against the handling of
intermediary MTAs.

DKIM self-signs the DKIM-Signature header field, to protect against
its being modified.

In order to survive the vagaries of different email transfer systems,
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
single space. DKIM has added the "relaxed" canonicalization in place
of "nofws".

12.1. What Needs To Be Moved Here From the Base Doc?

MUA considerations

key delegation/ 3rd party

9. Acknowledgements

TBD

10. Informative

13. References

13.1. References -- Normative

[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail Signatures
(DKIM)", draft-ietf-dkim-base-02 (DKIM)
Signatures", draft-ietf-dkim-base-05 (work in progress),
May
August 2006.

[I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11,

[RFC2822] Resnick, P., "Internet Message Format", RFC 822, August 1982. 2822,
April 2001.

13.2. Informative References

[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987.

[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
Object Security Services", RFC 1848, October 1995.

[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996.

[RFC2822] Resnick, P., "Internet Message Format",

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2822, 2821,
April 2001.

[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.

Authors' Addresses

Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA

Email: tony+dkimov@maillennium.att.com

Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
USA

Email: dcrocker@bbiw.net

Phillip Hallam-Baker
VeriSign Inc.
USA

Email: pbaker@verisign.com

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).