draft-ietf-dkim-overview-02.txt   draft-ietf-dkim-overview-03.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational D. Crocker Intended status: Informational D. Crocker
Expires: April 25, 2007 Brandenburg InternetWorking Expires: April 26, 2007 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
October 22, 2006 October 23, 2006
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-02 draft-ietf-dkim-overview-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2007. This Internet-Draft will expire on April 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
DomainKeys Identified Mail (DKIM) associates a "responsible" identity DomainKeys Identified Mail (DKIM) associates a "responsible" identity
with a message and provides a means of verifying that the association with a message and provides a means of verifying that the association
is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level
skipping to change at page 3, line 41 skipping to change at page 3, line 41
7.1. Development . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Development . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. DNS Server . . . . . . . . . . . . . . . . . . . . . . . 24
7.4. Accreditation service . . . . . . . . . . . . . . . . . . 24 7.4. Accreditation service . . . . . . . . . . . . . . . . . . 24
8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Transition strategy . . . . . . . . . . . . . . . . . . . 27 8.3. Transition strategy . . . . . . . . . . . . . . . . . . . 27
9. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. DNS Signature Record Deployment Considerations . . . . . 28 9.1. DNS Signature Record Deployment Considerations . . . . . 28
9.2. Private Key Management . . . . . . . . . . . . . . . . . 30
9.3. Mailing List Management . . . . . . . . . . . . . . . . . 31
10. Outline Future Extensions . . . . . . . . . . . . . . . . . . 31 10. Outline Future Extensions . . . . . . . . . . . . . . . . . . 31
10.1. Introducing a new signing algorithm . . . . . . . . . . . 32 10.1. Introducing a new signing algorithm . . . . . . . . . . . 32
10.2. Possible future signature algorithm choices . . . . . . . 32 10.2. Possible future signature algorithm choices . . . . . . . 33
10.3. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33 10.3. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 33
10.4. Trusted Third Party Assertions . . . . . . . . . . . . . 33 10.4. Trusted Third Party Assertions . . . . . . . . . . . . . 34
10.5. Linkage to X.509 Certificates . . . . . . . . . . . . . . 34 10.5. Linkage to X.509 Certificates . . . . . . . . . . . . . . 35
10.6. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.6. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.7. Verification in the Client . . . . . . . . . . . . . . . 36 10.7. Verification in the Client . . . . . . . . . . . . . . . 36
10.8. Per user signature . . . . . . . . . . . . . . . . . . . 36 10.8. Per user signature . . . . . . . . . . . . . . . . . . . 36
10.9. Encryption . . . . . . . . . . . . . . . . . . . . . . . 37 10.9. Encryption . . . . . . . . . . . . . . . . . . . . . . . 37
10.10. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 37 10.10. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 38
10.11. Use of Policy Record . . . . . . . . . . . . . . . . . . 38 10.11. Use of Policy Record . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
12. { Misc Text -- Should go elsewhere, if used at all } . . . . . 38 12. { Misc Text -- Should go elsewhere, if used at all } . . . . . 39
12.1. What Needs To Be Moved Here From the Base Doc? . . . . . 39 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. References -- Normative . . . . . . . . . . . . . . . . . 40
13.1. References -- Normative . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 40 13.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. Introduction 1. Introduction
This document provides an overview of DomainKeys Identified Mail This document provides an overview of DomainKeys Identified Mail
(DKIM). It is intended for those who are adopting, developing, or (DKIM). It is intended for those who are adopting, developing, or
deploying DKIM. It also will be helpful for those who are deploying DKIM. It also will be helpful for those who are
considering extending DKIM, either into other areas or to support considering extending DKIM, either into other areas or to support
additional features. This Overview does not provide information on additional features. This Overview does not provide information on
threats to DKIM or email, or details on the protocol specifics, which threats to DKIM or email, or details on the protocol specifics, which
can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats], can be found in [I-D.ietf-dkim-base] and [I-D.ietf-dkim-threats],
skipping to change at page 6, line 11 skipping to change at page 6, line 11
level signatures or make use of keys stored in the DNS. However the level signatures or make use of keys stored in the DNS. However the
currently deployed base does not and modifying it to do so would currently deployed base does not and modifying it to do so would
require extensive effort. require extensive effort.
Unlike all four previous IETF email security initiatives, DKIM Unlike all four previous IETF email security initiatives, DKIM
employs a key centric Public Key Infrastructure (PKI) as opposed to employs a key centric Public Key Infrastructure (PKI) as opposed to
one that is based on a certificate in the style of Kohnfelder (X.509) one that is based on a certificate in the style of Kohnfelder (X.509)
or Zimmerman (web of trust). That is, the owner of a key asserts its or Zimmerman (web of trust). That is, the owner of a key asserts its
validity, rather than relying on having a broader semantic validity, rather than relying on having a broader semantic
implication of the assertion, such as a quality assessment of the implication of the assertion, such as a quality assessment of the
key's owner/. DKIM treats quality assessment as an independent, key's owner. DKIM treats quality assessment as an independent,
value-added service, beyond the initial work of deploying a value-added service, beyond the initial work of deploying a
validating signature service. validating signature service.
NOTE: It would be useful to include a citation to a general NOTE: It would be useful to include a citation to a general
discussion about PKI issues, including their long history of discussion about PKI issues, including their long history of
difficulties with respect to the Internet. difficulties with respect to the Internet.
Further, DKIM's PKI is supported as additional information records to Further, DKIM's PKI is supported as additional information records to
the existing Domain Name Service, rather than requiring deployment of the existing Domain Name Service, rather than requiring deployment of
a new query infrastructure. This approach also has significant a new query infrastructure. This approach also has significant
performance advantages as DNS is layers on UDP and key retrieval is performance advantages as DNS is layered on UDP and key retrieval is
typically achieved in a single round trip. typically achieved in a single round trip.
2. The DKIM Value Proposition 2. The DKIM Value Proposition
Spam can be understood as two separate problems. The first is the Spam can be understood as two separate problems. The first is the
problem of the companies that are inappropriately aggressive, in problem of the companies that are inappropriately aggressive, in
sending out unsolicited marketing email. This accounts for, perhaps, sending out unsolicited marketing email. This accounts for, perhaps,
5% of the spam volume and is in any case usually handled by existing 5% of the spam volume and is in any case usually handled by existing
spam filters. The second problem is rogue spam -- often involving spam filters. The second problem is rogue spam -- often involving
criminal activities -- mostly sent from coerced botnets of criminal activities -- mostly sent from coerced botnets of
compromised machines. For this latter set of mail, the origins of a compromised machines. For this latter set of mail, the origins of a
message are often falsely stated. message are often falsely stated.
Even without the addition of independent accreditation services, DKIM Even without the addition of independent accreditation services, DKIM
allows pair-wise sets of (possibly large) email providers and spam allows pair-wise sets of (possibly large) email providers and spam
filtering companies to distinguish mail that is associated with a filtering companies to distinguish mail that is associated with a
known organization, from mail that might deceptively purport to have known organization, from mail that might deceptively purport to have
the affiliation. This in turn allows the development of 'whitelist' the affiliation. This in turn allows the development of 'whitelist'
schemes whereby authenticated mail from a known source with good schemes whereby authenticated mail from a known source with good
reputation is allowed to bypass spam filters. reputation is allowed to bypass some spam filters.
In effect the email receiver is using their set of known In effect the email receiver is using their set of known
relationships to generate their own accreditation/reputation data. relationships to generate their own accreditation/reputation data.
This works particularly well for traffic between large sending This works particularly well for traffic between large sending
providers and large receiving providers. However it also works well providers and large receiving providers. However it also works well
for any operator, public or private, that has mail traffic dominated for any operator, public or private, that has mail traffic dominated
by exchanges among a stable set of organizations. by exchanges among a stable set of organizations.
NOTE: Perhaps add some citations to detailed discussions about spam NOTE: Perhaps add some citations to detailed discussions about spam
and phishing and the role of authentication and accreditation in and phishing and the role of authentication and accreditation in
skipping to change at page 7, line 51 skipping to change at page 7, line 51
o is compatible with the existing email infrastructure and o is compatible with the existing email infrastructure and
transparent to the fullest extent possible transparent to the fullest extent possible
o requires minimal new infrastructure o requires minimal new infrastructure
o can be implemented independently of clients in order to reduce o can be implemented independently of clients in order to reduce
deployment time deployment time
o does not require the use of trusted third parties (e.g., o does not require the use of trusted third parties (e.g.,
certificate authorities) which might impose significant costs or certificate authorities) that might impose significant costs or
introduce delays to deployment introduce delays to deployment
o can be deployed incrementally o can be deployed incrementally, with separate deployment of signers
and verifiers in either order
o allows delegation of signing to third parties o allows delegation of signing to third parties
o is not intended be used for archival purposes o is not intended be used for archival purposes
DKIM authentication provides one link in a chain of responsibility, DKIM authentication provides one link in a chain of responsibility,
hopefully leading to better accountability by the senders. hopefully leading to better accountability by the senders.
3.1. Treat verification failure as if unsigned. 3.1. Treat verification failure as if unsigned.
PGP and S/MIME were both designed for strong cryptographic PGP and S/MIME were both designed for strong cryptographic
protection. This included treating validation failure as message protection. This included treating validation failure as message
failure, at least warning the user that the message was unsigned. In failure, at least warning the user that the message was unsigned. In
a small number of cases the application went even further 'warning' a small number of cases the application went even further by
the user whenever a signed message was received. This approach has 'warning' the user whenever a signed message was received. This
proved problematic. Hence for DKIM, the guidance is that an email approach has proved problematic. Hence for DKIM, the guidance is
signature verifier is to treat messages with signatures that fail as that an email signature verifier is to treat messages with signatures
if they were unsigned. that fail as if they were unsigned.
It is highly unlikely that an attacker is going to add a digital It is highly unlikely that an attacker is going to add a digital
signature to a message unless doing so causes the message to be signature to a message unless doing so causes the message to be
treated more favorably than an unsigned one. Any messages that carry treated more favorably than an unsigned one. Any messages that carry
signatures that fail verification are thus much more likely to be a signatures that fail verification are thus much more likely to be a
genuine message that has been damaged in transit than an attempted genuine message that has been damaged in transit than an attempted
forgery. It makes no sense to warn the recipient unless it is known forgery. It makes no sense to warn the recipient unless it is known
that the sender always signs email messages and that there is a high that the sender always signs email messages and that there is a high
probability that a forgery would be attempted. probability that a forgery would be attempted.
skipping to change at page 8, line 46 skipping to change at page 8, line 47
PGP and S/MIME apply the end-to-end principle in terms of individual PGP and S/MIME apply the end-to-end principle in terms of individual
originators and recipients, notably using full email addresses. DKIM originators and recipients, notably using full email addresses. DKIM
seeks accountability at the more coarse grain of an organization or, seeks accountability at the more coarse grain of an organization or,
perhaps, a department. A deployed construct that enables this perhaps, a department. A deployed construct that enables this
granularity is the domain name, to which the signing key record is granularity is the domain name, to which the signing key record is
bound. bound.
3.3. Incremental adoption 3.3. Incremental adoption
DKIM can immediately provide benefit between any two organizations DKIM can immediately provide benefits between any two organizations
that exchange email and implement DKIM. In the usual manner of that exchange email and implement DKIM. In the usual manner of
"network effects", the benefits of DKIM increase dramatically as its "network effects", the benefits of DKIM increase dramatically as its
adoption increases. adoption increases.
Over time, DKIM adoption might become sufficiently widespread to Over time, DKIM adoption might become sufficiently widespread to
permit special, negative handling of messages that are not signed. permit special, negative handling of messages that are not signed.
However early benefits do not require this more-stringent However early benefits do not require this more-stringent
enforcement. enforcement.
3.4. Minimal infrastructure 3.4. Minimal infrastructure
skipping to change at page 9, line 26 skipping to change at page 9, line 28
over the open Internet. over the open Internet.
Even with use of the DNS, one challenge is that it is usually Even with use of the DNS, one challenge is that it is usually
operated by different administrative staff than those who operate an operated by different administrative staff than those who operate an
organization's email service. In order to ensure that DKIM DNS organization's email service. In order to ensure that DKIM DNS
records are accurate, this imposes a requirement for careful records are accurate, this imposes a requirement for careful
coordination between the two operations groups. coordination between the two operations groups.
3.5. Transparent signature 3.5. Transparent signature
S/MIME and PGP are both modify the message body. Hence, their S/MIME and PGP both modify the message body. Hence, their presence
presence is visible to all email recipients and their user software is visible to all email recipients and their user software must be
must be able to process the associated constructs. In order to able to process the associated constructs. In order to facilitate
facilitate incremental adoption, DKIM is designed to be transparent incremental adoption, DKIM is designed to be transparent to
for recipients that do not support it. recipients that do not support it.
3.6. Security policy 3.6. Security policy
DKIM is pursuing an incremental innovation, over basic identity DKIM is pursuing an incremental innovation, over basic identity
authentication, through the publication of security policies authentication, through the publication of security policies
associated with one or of the identities presented in a message. For associated with one or of the identities presented in a message. For
example, a valid DKIM signature allows the signing party to assert example, a valid DKIM signature allows the signing party to assert
responsibility for a message . For a recipient to interpret an responsibility for a message . For a recipient to interpret an
unsigned message it is necessary to know whether it should expect a unsigned message it is necessary to know whether it should expect a
message from that source to be signed and if so the signature message from that source to be signed and if so the signature
skipping to change at page 10, line 39 skipping to change at page 10, line 40
are coded into the DKIM-Signature header field. Selectors are are coded into the DKIM-Signature header field. Selectors are
assigned according to the administrative needs of the signing domain, 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 such as for rolling over to a new key or for delegating of the right
to authenticate a portion of the namespace to a trusted third party. to authenticate a portion of the namespace to a trusted third party.
Examples include: jun2005.eng._domainkey.example.com Examples include: jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.com widget.promotion._domainkey.example.com
NOTE: It is intended that assessments of DKIM identities be based NOTE: It is intended that assessments of DKIM identities be based
on the domain name, rather than include the selector. This on the domain name, and not include the selector. This permits
permits the selector to be used only for key administration, the selector to be used only for key administration, rather than
rather than having an effect on reputation assessment. having an effect on reputation assessment.
4.3. Who validates the signature? 4.3. Who validates the signature?
After a message has been signed, any agent in the message transit After a message has been signed, any agent in the message transit
path can choose to validate the signature. Validation of the path can choose to validate the signature. Validation of the
signature, by a later agent in the path, demonstrates that the signature, by a later agent in the path, demonstrates that the
signing identity took responsibility for the message signing identity took responsibility for the message
Message recipients can verify the signature by querying the signer's Message recipients can verify the signature by querying the signer's
domain directly to retrieve the appropriate public key, and thereby domain directly to retrieve the appropriate public key, and thereby
skipping to change at page 12, line 13 skipping to change at page 12, line 13
TBD TBD
5. DKIM Within Existing Internet Email 5. DKIM Within Existing Internet Email
5.1. Review of Internet Mail Service Architecture 5.1. Review of Internet Mail Service Architecture
Internet Mail has a simple split between the user world, in the form Internet Mail has a simple split between the user world, in the form
of Mail User Agents (MUA), and the transmission world, in the form of of Mail User Agents (MUA), and the transmission world, in the form of
the Mail Handling Service (MHS) composed of Mail Transfer Agents the Mail Handling Service (MHS) composed of Mail Transfer Agents
(MTA). The MHS is responsible for accepting a message from one User (MTA). The MHS is responsible for accepting a message from one User
and delivering it to one or more others, creating a virtual MUA-to- and delivering it to one or more other users, creating a virtual MUA-
MUA exchange environment. The first MTA is called the Mail to-MUA exchange environment. The first MTA is called the Mail
Submission Agent (MSA) and the final MTA is called the Mail Delivery Submission Agent (MSA) and the final MTA is called the Mail Delivery
Agent (MDA) Agent (MDA)
+--------+ +--------+
+---------------->| User | +---------------->| User |
| +--------+ | +--------+
| ^ | ^
+--------+ | +--------+ . +--------+ | +--------+ .
| User +--+--------->| User | . | User +--+--------->| User | .
+--------+ | +--------+ . +--------+ | +--------+ .
skipping to change at page 13, line 11 skipping to change at page 13, line 11
other components for performing message transfer. Consequently, it other components for performing message transfer. Consequently, it
is necessary to distinguish administrative boundaries that surround is necessary to distinguish administrative boundaries that surround
sets of functional components. sets of functional components.
5.1.1. Administrative Actors 5.1.1. Administrative Actors
Operation of Internet Mail services is apportioned to different Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). An ADMD operates with an ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust.. Examples include an end- to differing types and amounts of trust. Examples include an end-
user operating their desktop client, a department operating a local user operating their desktop client, a department operating a local
Relay, an IT department operating an enterprise Relay and an ISP Relay, an IT department operating an enterprise Relay and an ISP
operating a public shared email service. These can be configured operating a public shared email service. These can be configured
into many combinations of administrative and operational into many combinations of administrative and operational
relationships, with each ADMD potentially having a complex relationships, with each ADMD potentially having a complex
arrangement of functional components. Figure 2 depicts the arrangement of functional components. Figure 2 depicts the
relationships among ADMDs. Perhaps the most salient aspect of an relationships among ADMDs. Perhaps the most salient aspect of an
ADMD is the differential trust that determines its policies for ADMD is the differential trust that determines its policies for
activities within the ADMD, versus those involving interactions with activities within the ADMD, versus those involving interactions with
other ADMDs. other ADMDs.
skipping to change at page 15, line 11 skipping to change at page 15, line 11
Mail Service Providers -- Operating email services, such as for Mail Service Providers -- Operating email services, such as for
end-users, or mailing lists. end-users, or mailing lists.
5.1.2. Field Referencing Convention 5.1.2. Field Referencing Convention
In this document, references to structured fields of a message use a In this document, references to structured fields of a message use a
two-part dotted notation. The first part cites the document that two-part dotted notation. The first part cites the document that
contains the specification for the field and the second is the name 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 of the field. Hence <RFC2822.From> is the From field in an email
content header and <RFC2821.MailFrom> [RFC2821] is the address in the content header [RFC2822] and <RFC2821.MailFrom> is the address in the
SMTP "Mail From" command. SMTP "Mail From" command. [RFC2821]
5.2. Where to Place DKIM Functions 5.2. Where to Place DKIM Functions
DKIM associates a "responsible" identity with a message and provides DKIM associates a "responsible" identity with a message and provides
a means of verifying that the association is legitimate. Deciding a means of verifying that the association is legitimate. Deciding
which ADMD shall perform signing or verifying, which identity to which ADMD shall perform signing or verifying, which identity to
assign and which functional components to use for DKIM processing assign and which functional components to use for DKIM processing
depend upon the nature of the trust/reputation that is of interest depends upon the nature of the trust/reputation that is of interest
and the most convenient or efficient way to use it. and the most convenient or efficient way to use it.
Messages may be signed or verified by any functional component within Messages may be signed or verified by any functional component within
an ADMD, as that domain wishes to arrange. Examples include: an ADMD, as that domain wishes to arrange. Examples include:
Outbound -- MUA, MSA or boundary MTA. Outbound -- MUA, MSA or boundary MTA.
Inbound -- Boundary MTA, MDA or MUA. Inbound -- Boundary MTA, MDA or MUA.
By having an MUA do the signing or verifying, there is no dependence By having an MUA do the signing or verifying, there is no dependence
skipping to change at page 16, line 46 skipping to change at page 16, line 46
reputation-related verification will be to place the signature reputation-related verification will be to place the signature
verification function "close" to the message-filtering engine. verification function "close" to the message-filtering engine.
5.3. Impact on Email Activities 5.3. Impact on Email Activities
5.3.1. Resources 5.3.1. Resources
Although cryptographic authentication is considered to be Although cryptographic authentication is considered to be
computationally expensive, the real impact of a mechanism like DKIM computationally expensive, the real impact of a mechanism like DKIM
is remarkably small. Direct impact on CPU-load has been measured to is remarkably small. Direct impact on CPU-load has been measured to
be 10-15%. Mail handling tends to be, i/o-intensive, so that be 10-15%. Mail handling tends to be I/O-intensive, so dedicated
dedicated email platforms tend to have unused computational capacity. email platforms tend to have unused computational capacity. It is
It is therefore likely that no new hardware will be required for therefore likely that no new hardware will be required for these
these systems to be able to add DKIM support. systems to be able to add DKIM support.
5.3.2. Operations 5.3.2. Operations
The costs to deploy, administer and operate DKIM vary greatly, The costs to deploy, administer and operate DKIM vary greatly,
depending upon the placement of DKIM-related modules. The greatest depending upon the placement of DKIM-related modules. The greatest
flexibility comes from placing the modules as close as possible to flexibility comes from placing the modules as close as possible to
the end user. However this also imposes the greatest costs. The the end user. However this also imposes the greatest costs. The
most common scenarios are likely to be: most common scenarios are likely to be:
Boundary MTA -- Here, DKIM is used only for email external to the Boundary MTA -- Here, DKIM is used only for email external to the
skipping to change at page 17, line 25 skipping to change at page 17, line 25
cause problems for mobile users who are associated with the cause problems for mobile users who are associated with the
organization but must send mail using facilities that are organization but must send mail using facilities that are
independent of their home ADMD. It also provides no assistance independent of their home ADMD. It also provides no assistance
for inter-departmental accountability within the ADMD.. for inter-departmental accountability within the ADMD..
MSA/MDA (Department) -- Placing DKIM support at the points of MSA/MDA (Department) -- Placing DKIM support at the points of
submission and delivery increases the deployment costs but still submission and delivery increases the deployment costs but still
keeps control within the ADMD's operational staff. It avoids the keeps control within the ADMD's operational staff. It avoids the
considerable, added costs of having to enhance all of the MUAs. considerable, added costs of having to enhance all of the MUAs.
This does not improve the lot of mobile users who submit from This does not improve the lot of mobile users who submit from
independent MSAs but does provide full protection within the ADMD. independent MSAs, but does provide full protection within the
ADMD.
MUA -- Obviously this can provide the most complete protection, but MUA -- Obviously this can provide the most complete protection, but
at the cost of considerable added administrative effort. Worse, at the cost of considerable added administrative effort. Worse,
there is extensive evidence that email infrastructure services there is extensive evidence that email infrastructure services
often perform changes to message content that can break a message often perform changes to message content that can break a message
signature. Examples include transformation by the MSA to ensure signature. Examples include transformation by the MSA to ensure
that the message is in full conformance with Internet standards that the message is in full conformance with Internet standards
and transformation by Boundary MTAs, to ensure conformance with and transformation by Boundary MTAs, to ensure conformance with
organizational policies about external communications. organizational policies about external communications.
In spite of these concerns, placing DKIM support into the MUA is Placing DKIM support into the MUA is the only way to ensure that a
the only way to ensure that a highly mobile user retains its highly mobile user retains all of its benefits, in spite of these
benefits, in spite of having to send mail through independent concerns and having to send mail through independent MSAs.
MSAs.
Challenge of mobile users. Server-resident folders -- web or imap -- TBD ... Challenge of mobile users. Server-resident folders -- web
no problem. Laptop-resident folders, requires remote MSA access or or imap -- no problem. Laptop-resident folders, requires remote MSA
per-user keying and mobile-author awareness. access or per-user keying and mobile-author awareness.
Key creation and replacement. Update DNS and signing component Key creation and replacement. Update DNS and signing component
5.3.3. Users 5.3.3. Users
Challenge of mobile users. Server-resident folders -- web or imap -- TBD ... Challenge of mobile users. Server-resident folders -- web
no problem. Laptop-resident folders, requires remote MSA access or or imap -- no problem. Laptop-resident folders, requires remote MSA
per-user keying and mobile-author awareness. access or per-user keying and mobile-author awareness.
Challenge of mailing lists. Different list styles warrant different Challenge of mailing lists. Different list styles warrant different
signature policies. signature policies.
Can be hidden from end-user; used by filter engine. Method and Can be hidden from end-user; used by filter engine. Method and
benefits for displaying to users unknown. benefits for displaying to users unknown.
5.4. Migrating from DomainKeys 5.4. Migrating from DomainKeys
5.4.1. Signing 5.4.1. Signing
DNS Records: DKIM is upward compatible with existing DomainKeys DNS Records: DKIM is upward compatible with existing DomainKeys
(DK) DNS records, so that a DKIM module does not automatically (DK) DNS records, so that a DKIM module does not automatically
require additional DNS administration! DKIM has enhanced the DK require additional DNS administration! DKIM has enhanced the
DNS key record, to permit the addition of several parameters. DomainKeys DNS key record format by adding several optional
parameters.
Boundary MTA: Enforce signature policies and practices Boundary MTA: Enforce signature policies and practices
> >
5.4.2. Verifying 5.4.2. Verifying
DNS Client: TBD DNS Client: TBD
Verifying module: See "Signing Module". Verifying module: See "Signing Module".
skipping to change at page 22, line 23 skipping to change at page 22, line 23
Means of verifying that the signer configuration is compatible with Means of verifying that the signer configuration is compatible with
the signature policy is also highly desirable. the signature policy is also highly desirable.
Disclosure of a private signature key component to a third party Disclosure of a private signature key component to a third party
allows that third party to impersonate the sender. Protection of allows that third party to impersonate the sender. Protection of
private signature key data is therefore a critical concern. Signers private signature key data is therefore a critical concern. Signers
SHOULD support use of cryptographic hardware providing key management SHOULD support use of cryptographic hardware providing key management
features. features.
The import and export of private keys, and the ability to generate a The import and export of private keys, and the ability to generate a
CSR for certificate registration are highly desirable. Certificate Signing Request (CSR) for certificate registration are
highly desirable.
7.1.1.2. Verifier 7.1.1.2. Verifier
Verifiers SHOULD treat the result of the verification step as an Verifiers SHOULD treat the result of the verification step as an
input to the message evaluation process rather than as providing a input to the message evaluation process rather than as providing a
final decision. The knowledge that a message is authentically sent final decision. The knowledge that a message is authentically sent
by a domain does not say much about the legitimacy of the message by a domain does not say much about the legitimacy of the message,
unless the characteristics of the domain claiming responsibility are unless the characteristics of the domain claiming responsibility are
known. known.
In particular, verifiers SHOULD NOT automatically assume that a email In particular, verifiers SHOULD NOT automatically assume that an
message that does not contain a signature or which contains a email message that does not contain a signature, or that contains a
signature that does not validate is forged. Verifiers should treat a signature that does not validate, is forged. Verifiers should treat
signature that fails to validate as if no signature was present. a signature that fails to validate the same as if no signature were
present.
7.1.2. Email Handlers 7.1.2. Email Handlers
7.1.2.1. Mail User Agent 7.1.2.1. Mail User Agent
DKIM is designed to support deployment and use in email components DKIM is designed to support deployment and use in email components
other than an MUA. However an MUA may also however implement DKIM other than an MUA. However an MUA may also implement DKIM features
features directly. directly.
Outbound: If an MUA is configured to send email directly, rather Outbound: If an MUA is configured to send email directly, rather
than relayed through an outbound MTA, the MUA SHOULD be considered than relayed through an outbound MTA, the MUA SHOULD be considered
as if it were an outbound MTA for the purposes of DKIM. An MUA as if it were an outbound MTA for the purposes of DKIM. An MUA
MAY support signing even if mail is to be relayed through an MAY support signing even if mail is to be relayed through an
outbound MTA. In this case the signature applied by the MUA may outbound MTA. In this case the signature applied by the MUA may
be in addition to or in place of the MTA signature. be in addition to or in place of the MTA signature.
Inbound: An MUA MAY rely on a report of a DKIM signature Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA verification that took place at some point in the inbound MTA
path. An MUA MAY perform DKIM signature verification directly. path. An MUA MAY perform DKIM signature verification directly.
Such an MUA SHOULD allow for the case where mail is modified in Such an MUA SHOULD allow for the case where mail is modified in
the inbound MTA path. the inbound MTA path.
7.1.3. Mail Transfer Agent 7.1.3. Mail Transfer Agent
It is expected that the most common venue for a DKIM implementation It is expected that the most common venue for a DKIM implementation
with be a department or a boundary MTA. wil be a department or a boundary MTA.
Outbound: An Outbound MTA should allow for automatic verification Outbound: An Outbound MTA should allow for automatic verification
of the MTA configuration such that the MTA can generate an of the MTA configuration such that the MTA can generate an
operator alert if it determines that it is (1) an edge MTA, (2) operator alert if it determines that it is (1) an edge MTA, (2)
configured to send email messages that do not comply with the configured to send email messages that do not comply with the
published DKIM sending policy. published DKIM sending policy.
An outbound MTA should be aware that users may employ MUAs that An outbound MTA should be aware that users may employ MUAs that
add their own signatures and be prepared to take steps necessary add their own signatures and be prepared to take steps necessary
to ensure that the message sent is in compliance with the to ensure that the message sent is in compliance with the
advertised email sending policy. advertised email sending policy.
Inbound: An inbound that does not support DKIM, it should avoid Inbound: An inbound MTA that does not support DKIM should avoid
modifying messages in ways that prevent verification by other modifying messages in ways that prevent verification by other
MTAs, or MUAs to which the message may be forwarded. MTAs, or MUAs to which the message may be forwarded.
Intermediaries: An email intermediary is both an inbound and Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the sections outbound MTA. Each of the requirements outlined in the sections
relating to MTAs apply. If the intermediary modifies a message in relating to MTAs apply. If the intermediary modifies a message in
a way that breaks the signature the intermediary it SHOULD a way that breaks the signature, the intermediary SHOULD
* deploy abuse filtering measures on the inbound mail * deploy abuse filtering measures on the inbound mail
* remove all signatures that will be broken * remove all signatures that will be broken
In addition the intermediary MAY: In addition the intermediary MAY:
* Verify the message signature prior to modification * Verify the message signature prior to modification
* Incorporate an Authentication-Results header to report the * Incorporate an Authentication-Results header to report the
skipping to change at page 24, line 20 skipping to change at page 24, line 20
The efficacy of a filtering scheme cannot therefore be determined by The efficacy of a filtering scheme cannot therefore be determined by
reference to static test vectors alone; resistance to counter attack reference to static test vectors alone; resistance to counter attack
must also be considered. must also be considered.
Naive learning algorithms that only consider the presence or absence Naive learning algorithms that only consider the presence or absence
of a valid DKIM signature are vulnerable to an attack in which a of a valid DKIM signature are vulnerable to an attack in which a
spammer or other malefactor signs all their mail, thus creating a spammer or other malefactor signs all their mail, thus creating a
large negative value for presence of a DKIM signature in the hope of large negative value for presence of a DKIM signature in the hope of
discouraging widespread use. discouraging widespread use.
If heuristic algorithms are employed they should be trained on If heuristic algorithms are employed, they should be trained on
feature sets that sufficiently reveal the internal structure of the feature sets that sufficiently reveal the internal structure of the
DKIM responses. In particular the algorithm should consider the DKIM responses. In particular the algorithm should consider the
domains purporting to claim responsibility for the signature rather domains purporting to claim responsibility for the signature, rather
than the existence of a signature or not. than the existence of a signature or not.
Unless a scheme can correlate the DKIM signature with accreditation Unless a scheme can correlate the DKIM signature with accreditation
or reputation data, the presence of a DKIM signature SHOULD be or reputation data, the presence of a DKIM signature SHOULD be
ignored. ignored.
7.3. DNS Server 7.3. DNS Server
TBD TBD
skipping to change at page 25, line 10 skipping to change at page 25, line 10
8.1. Signing 8.1. Signing
Creating messages that have DKIM signatures requires modification of Creating messages that have DKIM signatures requires modification of
only two portions of the email service: only two portions of the email service:
o Addition of relevant DNS information. o Addition of relevant DNS information.
o Addition of the signature by a trusted module within the o Addition of the signature by a trusted module within the
organization's email handling service. organization's email handling service.
The signing module uses the appropriate private key, for creating a The signing module uses the appropriate private key to create a
signature. The means by which the signing module obtains this key is signature. The means by which the signing module obtains this key is
not specified by DKIM. Given that DKIM is intended for use during not specified by DKIM. Given that DKIM is intended for use during
email transit, rather than for long-term storage, it is expected that email transit, rather than for long-term storage, it is expected that
keys will be changed regularly. Clearly this means that key keys will be changed regularly. Clearly this means that key
information should not be hard-coded into software. information should not be hard-coded into software.
8.1.1. DNS Records 8.1.1. DNS Records
A receiver attempting to validate a DKIM signature must obtain the A receiver attempting to validate a DKIM signature must obtain the
public key that is associated with the signature for that message. public key that is associated with the signature for that message.
The DKIM-Signature header in the message will specify the basic The DKIM-Signature header in the message will specify the basic
domain name doing the signing and the selector to be used for the domain name doing the signing and the selector to be used for the
specific public key. Hence, the relevant specific public key. Hence, the relevant
<selector>._domainkeys.<domain-name> DNS record needs to contain a <selector>._domainkeys.<domain-name> DNS record needs to contain a
DKIM-related RR that provides the public key information. DKIM-related RR that provides the public key information.
The administrator of the zone containing the relevant domain name The administrator of the zone containing the relevant domain name
adds this information. DNS administrative software varies adds this information. DNS administrative software varies
considerably in its abilities to add new (types of) DNS records. considerably in its abilities to add new types of DNS records.
Initial DKIM DNS information is contained within TXT RRs. Initial DKIM DNS information is contained within TXT RRs.
8.1.2. Signing Module 8.1.2. Signing Module
The module doing signing can be placed anywhere within an The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain (ADMD). organization's trusted Administrative Management Domain (ADMD).
Common choices are expected to be department-level posting and Common choices are expected to be department-level posting and
delivering agents, as well as boundary MTAs to the open Internet. delivering agents, as well as boundary MTAs to the open Internet.
However, note that it is entirely acceptable to have signing and However, note that it is entirely acceptable to have signing and
validation be done by MUAs. Hence the choice among the modules validation be done by MUAs. Hence the choice among the modules
skipping to change at page 26, line 5 skipping to change at page 26, line 5
by implementing the mechanism "deeper" into the organization's email by implementing the mechanism "deeper" into the organization's email
infrastructure, such as at its boundary MTA. infrastructure, such as at its boundary MTA.
8.1.3. Signing Policies and Practices 8.1.3. Signing Policies and Practices
Every organization (ADMD) will have its own policies and practices Every organization (ADMD) will have its own policies and practices
for deciding when to sign messages and with what domain name and key for deciding when to sign messages and with what domain name and key
(selector). Examples include signing all mail, signing mail from (selector). Examples include signing all mail, signing mail from
particular email addresses, or signing mail from particular sub- particular email addresses, or signing mail from particular sub-
domains. Given this variability, and the likelihood that signing domains. Given this variability, and the likelihood that signing
practices will change over time, it will useful to have these practices will change over time, it will be useful to have these
decisions represented in some sort of configuration information, decisions represented in some sort of configuration information,
rather than being more deeply coded into the signing software. rather than being more deeply coded into the signing software.
8.2. Verifying 8.2. Verifying
Verification is performed within an ADMD that wishes to make Verification is performed within an ADMD that wishes to make
assessments based upon the domain name used for a DKIM signature. assessments based upon the domain name used for a DKIM signature.
Any component within the ADMD that handles messages, whether in Any component within the ADMD that handles messages, whether in
transit or being delivered, can be appropriate to do the verifying. transit or being delivered, can be appropriate to do the verifying.
It must communicate the results of verification to another component It must communicate the results of verification to another component
skipping to change at page 26, line 35 skipping to change at page 26, line 35
and operational ease. An added concern is that the linkage between and operational ease. An added concern is that the linkage between
verification and assessment entails essential trust: The assessment verification and assessment entails essential trust: The assessment
module must have a strong basis for believing that the verification module must have a strong basis for believing that the verification
information is correct. information is correct.
8.2.1. DNS Client 8.2.1. DNS Client
The primary means of publishing DKIM key information, initially, is The primary means of publishing DKIM key information, initially, is
through DNS TXT records. Some DNS client software might have through DNS TXT records. Some DNS client software might have
problems obtaining these records. As DNS client software improves problems obtaining these records. As DNS client software improves
this will not be an concern. this will not be a concern.
8.2.2. Boundary Enforcement 8.2.2. Boundary Enforcement
In order for an assessment module to trust the information it In order for an assessment module to trust the information it
receives about verification, it is essential to eliminate receives about verification, it is essential to eliminate
verification information originating from outside the ADMD in which verification information originating from outside the ADMD in which
the assessment mechanism operates. As a matter of friendly practice, the assessment mechanism operates. As a matter of friendly practice,
it is equally important to make sure that verification information, it is equally important to make sure that verification information
from within the ADMD, not escape out side of it. generated within the ADMD not escape outside of it.
In most environments, the easiest way to enforce this stripping of In most environments, the easiest way to enforce this stripping of
verification information is to place modules in the receiving and verification information is to place modules in the receiving and
sending Boundary MTA(s). For incoming mail, check for known means of sending Boundary MTA(s). For incoming mail, check for known means of
communicating verification information and remove it. The same communicating verification information and remove it. The same
applies for outgoing mail. applies for outgoing mail.
8.3. Transition strategy 8.3. Transition strategy
Deployment of a new signature algorithm without a 'flag day' requires Deployment of a new signature algorithm without a 'flag day' requires
skipping to change at page 27, line 22 skipping to change at page 27, line 22
DKIM achieves these requirements through two features. First a DKIM achieves these requirements through two features. First a
signed message may contain multiple signatures created by the same signed message may contain multiple signatures created by the same
signer. Secondly the security policy layer allows the signing signer. Secondly the security policy layer allows the signing
algorithms in use to be advertised, thus preventing a downgrade algorithms in use to be advertised, thus preventing a downgrade
attack. attack.
8.3.1. Signer transition strategy 8.3.1. Signer transition strategy
Let the old signing algorithm be A, the new signing algorithm be B. Let the old signing algorithm be A, the new signing algorithm be B.
The sequence of events by which a Signer may introduce a new signing The sequence of events by which a Signer may introduce a new signing
algorithm without disruption of service to legacy verifiers is as algorithm, without disruption of service to legacy verifiers, is as
follows: follows:
1. Signer signs with algorithm A 1. Signer signs with algorithm A
A. Signer advertises that it signs with algorithm A A. Signer advertises that it signs with algorithm A
2. Signer signs messages twice, first with algorithm A and algorithm 2. Signer signs messages twice, first with algorithm A and algorithm
B B
A. The signer tests new signing configuration A. The signer tests new signing configuration
B. Signer advertises that it signs with algorithm A and B. Signer advertises that it signs with algorithm A and
algorithm B algorithm B
3. Signer determines that support for Algorithm A is no longer 3. Signer determines that support for Algorithm A is no longer
necessary necessary
4. Signer determines that support for algorithm A it to be withdrawn 4. Signer determines that support for algorithm A is to be withdrawn
A. Signer removes advertisement for Algorithm A A. Signer removes advertisement for Algorithm A
B. Signer waits for cached copies of earlier signature policy to B. Signer waits for cached copies of earlier signature policy to
expire expire
C. Signer stops signing with Algorithm A C. Signer stops signing with Algorithm A
8.3.2. Verifier transition strategy 8.3.2. Verifier transition strategy
The actions of the verifier are independent of the signer's actions The actions of the verifier are independent of the signer's actions
and do not need to be performed in a particular sequence. The and do not need to be performed in a particular sequence. The
verifier may make a decision to cease accepting algorithm A without verifier may make a decision to cease accepting algorithm A without
first deploying support for algorithm B. Similarly a verifier may be first deploying support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring algorithm B to be upgraded to support algorithm B without requiring algorithm A to be
withdrawn. The decisions of the verifier must make are therefore: withdrawn. The decisions of the verifier must make are therefore:
o The verifier MAY change the degree of confidence associated with o The verifier MAY change the degree of confidence associated with
any signature at any time, including determining that a given any signature at any time, including determining that a given
signature algorithm provides a limited assurance of authenticity signature algorithm provides a limited assurance of authenticity
at a given key strength. at a given key strength.
* A verifier MAY chose to evaluate signature records in any order * A verifier MAY evaluate signature records in any order it
it chooses, including making use of the signature algorithm for chooses, including making use of the signature algorithm for
this purpose. choosing the order.
o The verifier MAY make a determination that Algorithm A does not o The verifier MAY make a determination that Algorithm A does not
offer a useful level of security, that the cost of verifying the offer a useful level of security, or that the cost of verifying
signature is less than the value of doing so. the signature is less than the value of doing so.
* In this case the verifier ignores signatures created using the * In this case the verifier ignores signatures created using the
algorithm A and references to algorithm A in policy records are algorithm A and references to algorithm A in policy records are
treated as if the algorithm is not implemented. treated as if the algorithm were not implemented.
o The verifier MAY decide to add support for additional signature o The verifier MAY decide to add support for additional signature
algorithms at any time. algorithms at any time.
* The verified MAY add support for algorithm B at any time. * The verifier MAY add support for algorithm B at any time.
9. Operations 9. Operations
This section describes the basic steps for the continued operation of This section describes the basic steps for the continued operation of
email systems that use DKIM. This section discusses keeping DKIM email systems that use DKIM. This section discusses keeping DKIM
going, as opposed to getting DKIM started. The primary going, as opposed to getting DKIM started. The primary
considerations are: the upkeep of the selector files, and the considerations are: the upkeep of the selector files, and the
security of the private keys. security of the private keys.
9.1. DNS Signature Record Deployment Considerations 9.1. DNS Signature Record Deployment Considerations
skipping to change at page 29, line 52 skipping to change at page 29, line 52
of the system or the private keys, you should change the selector. of the system or the private keys, you should change the selector.
9.1.2. Server Clusters 9.1.2. Server Clusters
TBD TBD
9.1.3. Deploying New Selectors 9.1.3. Deploying New Selectors
A primary consideration in changing the selector is remembering to A primary consideration in changing the selector is remembering to
change it. It needs to be a standard part of the operational staff change it. It needs to be a standard part of the operational staff
Methods and Procedures for your systems. Methods and Procedures for your systems. If they are separate, both
the mail team and the DNS team will be involved in deploying new
selectors.
When deploying a selector, it needs to be phased in: When deploying a new selector, it needs to be phased in:
1. generate the new public / private key pair and create a selector 1. generate the new public / private key pair and create a selector
record with the public key in it record with the public key in it
2. add the new selector record to your DNS 2. add the new selector record to your DNS
3. turn on signing with the new private key 3. verify that the new selector record can be used to verify
signatures
4. optionally back up the old private key in a secure location 4. turn on signing with the new private key
5. remove the old private key from your servers 5. optionally back up the old private key in a secure location
6. after a period of time, remove the old selector 6. remove the old private key from your servers
7. after a period of time, remove the old selector from your DNS
The time an unused selector should be kept in the DNS system is The time an unused selector should be kept in the DNS system is
dependent on the reason it's being changed. If the private key has dependent on the reason it's being changed. If the private key has
definitely been exposed, the corresponding selector should be removed definitely been exposed, the corresponding selector should be removed
immediately. Otherwise, longer periods are allowable. immediately. Otherwise, longer periods are allowable.
9.1.4. Subdomain Considerations 9.1.4. Subdomain Considerations
TBD TBD
9.1.5. Third party Signature Delegations 9.1.5. Third party Signature Delegations
Allowing third parties to sign email from your domain opens your Allowing third parties to sign email from your domain opens your
system security to include the security of the third party's systems. system security to include the security of the third party's systems.
At a minimum, you should not allow the third parties to use the same At a minimum, you should not allow the third parties to use the same
selector and private key as your main mail system. It is recommended selector and private key as your main mail system. It is recommended
that each third party be given their own private key and selector. that each third party be given their own private key and selector.
This limits the exposure for any given private key, and minimizes the This limits the exposure for any given private key, and minimizes the
impact if any given private key were exposed. impact if any given private key were exposed.
9.1.6. Mailing List Management 9.2. Private Key Management
The permissions of private key files must be carefully managed. If
key management hardware support is available, it should be used.
Auditing software should be used to periodically verify that the
private key files remain secure.
9.3. Mailing List Management
[ Note: this section may be controversial. ] [ Note: this section may be controversial. ]
A mailing list often provides facilities to its administrator to A mailing list often provides facilities to its administrator to
manipulate parts of the mail messages that are flowing through. The manipulate parts of the mail messages that are flowing through. The
desired goal is that messages flowing through the mailing list will desired goal is that messages flowing through the mailing list will
be verifiable by the recipient, which means that either the mailing be verifiable by the recipient, which means that either the mailing
list (or its MSA) must sign the message, or the mailing list must not list (or its MSA) must sign the message, or the mailing list must not
perform actions on the messages that will break existing DKIM perform actions on the messages that will break existing DKIM
signatures. To avoid breaking existing signatures, a mailing list signatures. To avoid breaking existing signatures, a mailing list
skipping to change at page 31, line 26 skipping to change at page 31, line 39
o If a mailing list cannot add its own DKIM signature, and must o If a mailing list cannot add its own DKIM signature, and must
modify the headers or body in a way that will break verification modify the headers or body in a way that will break verification
of existing DKIM-Signature headers, it should remove any existing of existing DKIM-Signature headers, it should remove any existing
DKIM-Signature headers. DKIM-Signature headers.
10. Outline Future Extensions 10. Outline Future Extensions
The design of DKIM is unapologetically focused on overcoming the need The design of DKIM is unapologetically focused on overcoming the need
for immediate deployment and achieving ubiquitous use in the near for immediate deployment and achieving ubiquitous use in the near
future. As such, the original design discussions have generally future. As such, the original design discussions generally tok the
taken the approach 'if in doubt, leave it out'. approach of 'if in doubt, leave it out'.
The need to exclude consideration of these features in the near term But the need to exclude consideration of these features in the near
is in no way intended to preclude their development at a later date. term was in no way intended to preclude their development at a later
Nor is the lack of a specification describing the use of DKIM with a date. Nor is the lack of a specification describing the use of DKIM
different PKI infrastructure intended to indicate an intention to with a different PKI infrastructure intended to indicate an intention
develop similar capabilities within the DKIM framework at a future to develop similar capabilities within the DKIM framework at a future
date. date.
DKIM is an example of 'Design for Deployment'. The need to support DKIM is an example of 'Design for Deployment', and the need to
rapid deployment has been the overriding priority. It has support rapid deployment has been the overriding priority. It has
traditionally been asserted that deployment of a flawed cryptographic traditionally been asserted that deployment of a flawed cryptographic
protocol is an almost unacceptable risk, and that bad security is protocol is an almost unacceptable risk, and that bad security is
worse than no security. Experience demonstrates otherwise. worse than no security; experience demonstrates otherwise. Informing
Informing users that email is insecure does not cause them to modify users that email is insecure does not cause them to modify their
their behavior to avoid dependence thereupon. Deployment of flawed behavior to avoid dependence thereupon. Deployment of flawed
cryptographic security systems such as SSL and WEP has been rectified cryptographic security systems such as SSL and WEP has been rectified
far more quickly than deployment of protocols such as IPSEC or DNSSEC far more quickly than deployment of protocols such as IPSEC or DNSSEC
where caution has prevailed. where caution has prevailed.
One possible future for DKIM is that it becomes the starting point One possible future for DKIM is that it becomes the starting point
for a new cryptographic infrastructure that eventually replaces for a new cryptographic infrastructure that eventually replaces
legacy systems including S/MIME and PGP. While this future is legacy systems including S/MIME and PGP. While this future is
certainly preferable to never achieving ubiquitous deployment of certainly preferable to never achieving ubiquitous deployment of
strong cryptographic security in the Internet, it would certainly strong cryptographic security in the Internet, it would certainly
take a long time to re-invent this particular wheel. Moreover the take a long time to re-invent this particular wheel. Moreover the
deployment of the proposed DKIM enhancements would face political deployment of the proposed DKIM enhancements would face political
opposition from the adherents to existing formats to be rendered opposition from the adherents to existing formats to be rendered
historical. A likely outcome of such a strategy is that the existing historical. A likely outcome of such a strategy is that the existing
two way standards stalemate between S/MIME and PGP would become a two way standards stalemate between S/MIME and PGP would become a
three way stalemate. three way stalemate.
Another possible future is that DKIM provides the 'bootstrap' that Alternatively, another possible future is that DKIM provides the
enables ubiquitous use of the legacy infrastructure, including the 'bootstrap' that enables ubiquitous use of the legacy infrastructure,
deployed base of PGP and S/MIME capable email clients and the including the deployed base of PGP and S/MIME capable email clients
existing business infrastructure of commercial Certificate and the existing business infrastructure of commercial Certificate
Authorities. Such a strategy would make use of DKIM in conjunction Authorities. Such a strategy would make use of DKIM in conjunction
with existing PKI standards such as PKIX and XKMS and leverage with existing PKI standards such as PKIX and XKMS and leverage
features of PGP and S/MIME where appropriate. features of PGP and S/MIME where appropriate.
10.1. Introducing a new signing algorithm 10.1. Introducing a new signing algorithm
Regardless of whether extension of the DKIM feature set is desirable, Regardless of whether extension of the DKIM feature set is desirable,
the need to replace the signature algorithm is practically a the need to replace the signature algorithm is practically a
certainty. The RSA signature algorithm at best provides equivalent certainty. The RSA signature algorithm at best provides equivalent
security to an 80 bit symmetric cipher when used with a 1024 bit key security to an 80 bit symmetric cipher when used with a 1024 bit key
[cite]. Extending the key size to 2048 bits improves the cipher [cite]. Extending the key size to 2048 bits improves the cipher
strength to only 112 bit equivalence. Achieving 128 bit security strength to only 112 bit equivalence. Achieving 128 bit security
requires a minimum of 3072 bits. Achieving equivalent cipher requires a minimum of 3072 bits. Achieving equivalent cipher
strength to a 192 bit symmetric algorithm requires a prohibitive key strength to a 192 bit symmetric algorithm requires a prohibitive key
size. size.
The choice of cryptographic algorithm affects the DKIM algorithm in The choice of cryptographic algorithm affects the DKIM algorithm in
two important ways. First there is the difficulty of storing keys in two important ways: First there is the difficulty of storing keys in
the DNS. Secondly there is the problem of handling larger the DNS. Secondly there is the problem of handling larger
signatures. signatures.
The default DNS response packet limit of 512 bytes places an The default DNS response packet limit of 512 bytes places an
effective upper bound of 4096 bits on a DKIM key. In practice the effective upper bound of 4096 bits on a DKIM key. In practice the
need for packaging, meta-data and the desirability of using DNSSEC to need for packaging, meta-data and the desirability of using DNSSEC to
sign the record reduces the upper bound to no more than 2048 bits. sign the record reduces the upper bound to no more than 2048 bits.
The size of the DKIM signature itself is a weaker constraint. Even The size of the DKIM signature itself is a weaker constraint. Even
so, while 1024 and even 2048 bit signatures are likely to be so, while 1024 and even 2048 bit signatures are likely to be
skipping to change at page 35, line 14 skipping to change at page 35, line 32
Typical commercially issued digital certificates are considerably Typical commercially issued digital certificates are considerably
larger (1-2 kb) than the 512 byte message size that DNS servers are larger (1-2 kb) than the 512 byte message size that DNS servers are
required to support as a minimum. Practical large scale PKI required to support as a minimum. Practical large scale PKI
deployment requires support for certificate chains in addition to the deployment requires support for certificate chains in addition to the
end entity certificate. Publication of a URL for the certificate or end entity certificate. Publication of a URL for the certificate or
certificate chain is therefore a more appropriate approach than certificate chain is therefore a more appropriate approach than
storing the certificate data itself in the DNS. storing the certificate data itself in the DNS.
The ability to support multiple key distribution mechanisms for the The ability to support multiple key distribution mechanisms for the
same key is highly desirable. For example a signer may support DNS same key is highly desirable. For example a signer may support DNS
based key distribution for the convenience and efficiency of based key distribution (for the convenience and efficiency of
transport based DKIM signature verifiers and an X.509 certificate transport based DKIM signature verifiers) as well as an X.509
certificate.
In other cases a signer may intentionally discourage transport In other cases a signer may intentionally discourage transport
verification by only providing an X.509 certificate. verification by only providing an X.509 certificate.
An X.509 application of particular interest is the use of DKIM as a An X.509 application of particular interest is the use of DKIM as a
signature format for Secure Internet Letterhead (Letterhead). signature format for Secure Internet Letterhead (Letterhead).
Letterhead employs X.509 certificates containing a LOGOTYPE attribute Letterhead employs X.509 certificates containing a LOGOTYPE attribute
extension [LOGOTYPE] to identify the certificate subject and/or extension [LOGOTYPE] to identify the certificate subject and/or
issuer to the user by means of a brand image such as a corporate issuer to the user by means of a brand image such as a corporate
logo. [PHB-NIST] logo. [PHB-NIST]
skipping to change at page 39, line 28 skipping to change at page 39, line 44
DKIM self-signs the DKIM-Signature header field, to protect against DKIM self-signs the DKIM-Signature header field, to protect against
its being modified. its being modified.
In order to survive the vagaries of different email transfer systems, In order to survive the vagaries of different email transfer systems,
mechanisms like DKIM must evaluate the message data in some canonical mechanisms like DKIM must evaluate the message data in some canonical
form, such as treating a string of spaces as tabs as if they were a form, such as treating a string of spaces as tabs as if they were a
single space. DKIM has added the "relaxed" canonicalization in place single space. DKIM has added the "relaxed" canonicalization in place
of "nofws". of "nofws".
12.1. What Needs To Be Moved Here From the Base Doc? MUA UI considerations
MUA considerations
key delegation/ 3rd party key delegation/ 3rd party
13. References 13. References
13.1. References -- Normative 13.1. References -- Normative
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM) Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-05 (work in progress), Signatures", draft-ietf-dkim-base-06 (work in progress),
August 2006. October 2006.
[I-D.ietf-dkim-threats] [I-D.ietf-dkim-threats]
Fenton, J., "Analysis of Threats Motivating DomainKeys Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work
in progress), May 2006. in progress), May 2006.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
13.2. Informative References 13.2. Informative References
 End of changes. 66 change blocks. 
116 lines changed or deleted 132 lines changed or added

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