Barry Leiba wrote:
Description of Working Group:
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 has produced 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.
I suggest replacing the last sentence with something more generic, to avoid the
debate about how much any of this pertains to spoofing, per se. Perhaps
instead
have a value proposition statement derived from the one in the Overview
abstract:
These mechanisms permit email receivers to make additional assessments
about
messages.
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 do
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
discuss a reasonable set of possible actions and strategies, and
analyze their likely effects on attacks and on normal email
delivery.
Delete the first sentence, per my concern above. At the least, the sentence
appears to be largely redundant with the preceding paragraph's last sentence.
Isn't the second sentence incorrect? Doesn't DKIM mandate treated a failed
validation the same as no signature present?
The previously chartered deliverables for the DKIM working group
have been completed:
* An informational RFC presenting a detailed threat analysis of,
and security requirements for, DKIM. (RFC 4686)
* A standards-track specification for DKIM signature and
verification. (RFC 4871, updated by RFC 5672)
* A standards-track specification for DKIM policy handling.
(RFC 5617)
* 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. (RFC 5585 and
draft-ietf-dkim-deployment, in its final stages)
(One previously chartered deliverable, a standards-track
specification for DKIM DNS Resource Record(s), was dropped by
agreement between the working group and the Area Directors.)
Do re-charters usually contain all this history?
The working group is now ready to switch its focus to refining and
advancing the DKIM protocols. The current deliverables for the
DKIM working group are these:
* Advance the base DKIM protocol (RFC 4871) to Draft Standard.
* Collect data on the deployment and interoperability of the
Author Domain Signing Practices protocol (RFC 5617), and
determine if/when it's ready to advance on the standards track.
Update it at Proposed Standard or advance it to Draft Standard,
as appropriate.
As before, several related topics remain 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.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html