|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: Mar 18, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the DKIM working group
is reported below.
|
|
|
|
The Internet mail protocols and infrastructure allow mail sent from one
domain to purport to be from another. While there are sometimes
legitimate reasons for doing this, it has become a source of general
confusion, as well as a mechanism for fraud and for distribution of
spam (when done illegitimately, it's called "spoofing"). The DKIM
working group will produce standards-track specifications that allow a
domain to take responsibility, using digital signatures, for having
taken part in the transmission of an email message and to
publish "policy" information about how it applies those signatures.
Taken together, these will assist receiving domains in detecting (or
ruling out) certain forms of spoofing as it pertains to the signing
domain.
The DKIM working group will produce a summary of the threats that are
addressed by the proposed standards-track specifications, while
acknowledging their limitations and scope. The DKIM working group will
also produce security requirements to guide their efforts, and will
analyze the impact on senders and receivers who are not using DKIM,
particularly any cases in which mail may be inappropriately labeled as
suspicious or spoofed.
While the techniques specified by the DKIM working group will not
prevent fraud or spam, they will provide a tool for defense against
them by assisting receiving domains in detecting some spoofing of
known domains. The standards-track specifications will not mandate any
particular action by the receiving domain when a signature fails to
validate. That said, with the understanding that guidance is necessary
for implementers, the DKIM documents should discuss a reasonable set
of possible actions and strategies, and analyze their likely effects
on attacks and on normal email delivery. The DKIM working group will
not attempt to establish requirements for trust relationships between
domains nor to specify reputation or accreditation systems.
The DKIM working group will consider mailing-list behaviour that is
currently deemed acceptable, will make every effort to allow such
mailing lists to continue to operate in a DKIM environment, and will
provide a plan for smooth transition of mailing lists that fail to
operate. The specifications will also advise mailing lists on how to
take advantage of DKIM if they should choose to do so.
The signatures will use public-key cryptography and will be based on
domain name identifiers. Public keys needed to validate the signatures
will be stored in the responsible identity's DNS hierarchy. The
specifications will be based on the following Internet Drafts:
|
|
| - |
draft-fenton-dkim-threats
|
| - |
draft-allman-dkim-base
|
| - |
draft-allman-dkim-ssp
|
|
These documents represent experimentation and consensus from a number
of designers and early implementors.
Experimentation has resulted in Internet deployment of these
specifications. Although not encouraged, non-backwards-compatible
changes to these specifications will be acceptable if the DKIM working
group determines that the changes are required to meet the group's
technical objectives.
The resulting protocols must meet typical criteria for success. In
addition to security, these include usability, scalability, ease of
deployment, and cryptographic algorithm independence.
To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group. These topics
include:
|
|
| - |
Reputation and accreditation systems. While we expect these to add
value to what is defined by the DKIM working group, their development
will be separate, and is out of scope for the DKIM working group.
|
| - |
Message content encryption.
|
| - |
Additional key management protocols or infrastructure.
|
| - |
Signatures that are intended to make long-term assertions beyond the
expected transit time of a message from originator to recipient,
which is normally only a matter of a few days at most.
|
| - |
Signatures that attempt to make strong assertions about the identity
of the message author, and details of user-level signing of messages
(as distinguished from domain-level keys that are restricted to
specific users).
|
| - |
Duplication of prior work in signed email, including S/MIME and
OpenPGP.
|
|
Once the primary goals are met, the DKIM working group may also study
whether to adopt a work item for specifying a common mechanism to
communicate the results of message verification to the message
recipient. The generation of a standards-track specification on this
topic will require an update to the DKIM working group charter.
The deliverables for the DKIM working group are these:
|
|
| - |
An informational RFC presenting a detailed threat analysis of, and
security requirements for, DKIM. IESG approval of this document is
a prerequisite for the submission of the standards-track
specifications.
|
| - |
A standards-track specification for DKIM signature and verification.
|
| - |
A standards-track specification for DKIM policy handling.
|
| - |
A standards-track specification for DKIM DNS Resource Record(s).
|
| - |
An informational RFC providing an overview of DKIM and how it can
fit into overall messaging systems, how it relates to other IETF
message signature technologies, implementation and migration
considerations, and outlining potential DKIM applications and
future extensions.
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC4686
09/2006
(29 p.)
[html]
[pdf(2)] |
J. Fenton |
|
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) |
|
This document provides an analysis of some threats against Internet
mail that are intended to be addressed by signature-based mail
authentication, in particular DomainKeys Identified Mail. It
discusses the nature and location of the bad actors, what their
capabilities are, and what they intend to accomplish via their
attacks.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4871
05/2007
(71 p.)
[html]
[pdf(2)] |
E. Allman
J. Callas
M. Delany
M. Libbey
J. Fenton
M. Thomas |
|
DomainKeys Identified Mail (DKIM) Signatures |
|
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today. Protection of email identity may assist in the
global control of "spam" and "phishing".
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5016
10/2007
(15 p.)
[html]
[pdf(2)] |
M. Thomas |
|
Requirements for a
DomainKeys Identified Mail (DKIM) Signing Practices Protocol |
|
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
for domains to assert responsibility for the messages they handle. A
related mechanism will allow an administrator to publish various
statements about their DKIM signing practices. This document defines
requirements for this mechanism, distinguishing between those that
must be satisfied (MUST), and those that are highly desirable
(SHOULD).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
dkim-deployment-01
ID Exists
Feb 25, 2008
(21 p.)
[pdf(2)]
[html]
|
T. Hansen
P. Hallam-Baker
D. Crocker |
|
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations |
|
DomainKeys Identified Mail (DKIM) associates a "responsible" identity
with a message and provides a means of verifying that the association
is legitimate. [RFC 4871] DKIM defines a domain-level authentication
framework for email using public-key cryptography and key server
technology. This permits verifying the source or intermediary for a
message, as well as the contents of messages. The ultimate goal of
this framework is to permit a signing domain to assert responsibility
for sending a message, thus proving and protecting the identity
associated with the message and the integrity of the messages itself,
while retaining the functionality of Internet email as it is known
today. Such protection of email identity may assist in the global
control of "spam" and "phishing". This document provides
implementation, deployment, operational and migration considerations
for DKIM.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
dkim-overview-09
ID Exists
Feb 25, 2008
(23 p.)
[pdf(2)]
[html]
|
T. Hansen
D. Crocker
P. Hallam-Baker |
|
DomainKeys Identified Mail (DKIM) Service Overview |
|
This document provides an overview of the DomainKeys Identified Mail
(DKIM) service and describes how it can fit into a messaging service.
It also describes how DKIM relates to other IETF message signature
technologies. It is intended for those who are adopting, developing,
or deploying DKIM. DKIM allows an organization to take
responsibility for transmitting a message, in a way that can be
validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents.
An organization may use one or more domain names to accomplish this.
DKIM defines a domain-level digital signature authentication
framework for email, using public-key cryptography and key server
technology [RFC 4871]. This permits verification of a message source,
an intermediary, or one of their agents, as well as the integrity of
its contents. DKIM will also provide a mechanism that permits
potential email signers to publish information about their email
signing practices; this will permit email receivers to make
additional assessments about messages. Such protection of email
identity can assist in the global control of "spam" and "phishing".
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
dkim-ssp-03
ID Exists
Feb 23, 2008
(20 p.)
[pdf(2)]
[html]
|
E. Allman
J. Fenton
M. Delany
J. Levine |
|
DKIM Author Signing Practices (ASP) |
|
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs). The primary DKIM protocol is described in
[RFC 4871]. This document describes the records that authors' domains
can use to advertise their practices for signing their outgoing mail,
and how other hosts can access those records.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
## DKIMwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
kucherawy-dkim-
reporting-02
ID Exists
Mar 12, 2008
(20 p.)
[pdf(2)]
[html]
|
M. Kucherawy |
|
Reporting of DKIM Verification Failures |
|
This memo presents an extension to the DomainKeys Identified Mail
(DKIM) specifications to allow public keys for verification to
include a reporting address to be used to report message verification
issues, and extends an Internet Message reporting format to be
followed when generating such reports.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
otis-dkim-
tpa-ssp-04
ID Exists
Mar 18, 2008
(21 p.)
[pdf(2)]
[html]
|
D. Otis |
|
DKIM Third-Party Authorization for Sender Signer Practices |
TPA-label is a DNS-based prefix mechanism for DKIM policy records as
a means to authorize Third-Party domains. This mechanism allows
first-party domains to autonomously authorize a range of third-party
domains in a scalable, individual DNS transaction. This
authorization extends the scope of DKIM policy assertions to supplant
more difficult to administer mechanisms. Alternatives for
facilitating third-party authorizations currently necessitate the
coordination between two or more domains by setting up selector/key
DNS records, DNS zone delegations, or the regular exchange of public/
private keys.
Checking DKIM policies may occur when a From header email-address is
not within the domain of a valid DKIM signature. When a Third-Party
signature is found, TPA-labels offer an efficient means for email
address domains to authorize specific third-party signing domains.
The scope of the authorization may separately assert identity
authentication for From and Sender and Resent-* headers for email-addresses
within the authorizing domain. Identity authentication can
be asserted by the scope of the authorization, even when signed by a
Third-Party domain. In addition, the RFC2821.MailFrom domain can
authorize domains for controlling DSNs.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
