On Nov 5, 2005, at 9:16 PM, Dave Crocker wrote:
However, the best way to gauge this probably is for you to specify
the text that you propose to have changed in the charter.
While there appears to be some support for imposing a requirement
that From header always be associated with the transmitting domain,
there is a lack of appreciation that an open-ended authorization
becomes the target of abuse. In the SSP scheme, the email-address
domain owner must deal with complaints. The only alternative for the
email-address domain owner is to employ close-ended authorizations.
This results is a very message double email-address being added in
every From header which only increases people's exposure to abuse. : (
There is an alternative to that approach. This alternative should
provide far greater abatement of abuse with a charter as follows:
DRAFT IETF WORKING GROUP CHARTER
14 Oct 2005
Domain Keys Identified Message (DKIM)
CHAIRS:
TBD
AREA DIRECTORS:
Russell Housley, Sam Hartman
AREA ADVISOR:
Russell Housley <housley(_at_)vigilsec(_dot_)com>
MAILING LISTS:
General Discussion: ietf-dkim(_at_)mipassoc(_dot_)org
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/
DESCRIPTION OF WORKING GROUP:
The Internet email protocols do not establish a verifiable domain
that can be held accountable for messages being sent. There are no
legitimate reasons for the domain accountable for the email message
transport system not to provide a means of verification. Once the
domain accountable for the transport of messages can be verified, an
ability to create credible "spoofs" will be greatly reduced. Such
"spoofing" protection would often require a comparison to purported
domains expressed within both the body and the headers of the
message. As a defensive measure, signing-domains could assert flags
within the signature to establish future expectations of their email-
address association with their signature.
It is common practice for an email-address within the From header to
present a domain that is different than the domain accountable for
the email message transport system, the signing-domain. This
practice represents a legitimate desire to convey the purported
author of the message. The entity being trusted is always the domain
accountable for the message transport system, where their reputation
at controlling any abuse of such trust must be assessed.
The DKIM working group will produce standards-track specifications
that verifies the domain accountable for the email message transport
system using digital signatures. Within the signatures, assertions
should be included that indicate what message-related information is
assured, and how this information should be associated with the
domain in the future. This establishes clear accountability where
complaints related to abuse would be sent to the signing-domain.
Responding to reports of abuse establishes reputations for basing
future message acceptance. Those with no history should be
constrained, and domains with a poor reputation should thereby be
excluded as the only practical means to abate much of the abuse.
The work related to this endeavour will include mechanisms to
facilitate the identification of compromised systems without
violating privacies by having personally identifiable information
required. To this end, there should be a means to identify the
account used to send spam or malware without requiring specific email-
addresses. This can be accomplished by including an opaque-
identifier within signature.
Related work will also include a mechanism to revoke specific
messages independent of the key that will be commonly shared by many
users. This is needed to avoid the impact of traffic of per-user or
even per-message keys with a short time-to-live. This should also
include a method to mitigate the overhead related to such a
revocation scheme.
Attempts at creating an email-address authorization scheme will be
considered out-of-scope, as these mechanisms are invariably related
to the author and produce an undesired effect of holding the email-
address domain owner unfairly accountable for abuse. An inability to
establish safe open-ended authorization prevents any practical means
to allow the email-address be independent of the email message
transport system. An often coerced closed authorization would be
highly disruptive. A scheme aimed at protecting the author, such as
S/MIME and OpenPGP, are independent of the email message transport.
These approaches afford less disruption of current practices, but
imposes greater expense and security risks.
The DKIM working group will produce summaries of the threats that are
addressed by the 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 valuable tool for defense
against them by allowing receiving domains to detect spoofing of
known domains. The standards-track specifications will not mandate
any particular action by the receiving domain when spoofing is
detected. The DKIM working group will not attempt to define such
actions, to establish requirements for trust relationships between
domains, or to specify reputation or accreditation systems.
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-otis-dkim-threats
* draft-allman-dkim-base
Since experimentation resulted in significant Internet deployment of
these specifications, the DKIM working group will make every
reasonable attempt to keep changes compatible with what is deployed,
making incompatible changes only when they are necessary for the
success of the specifications.
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, incuding 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 will require an
update to
the DKIM working group charter.
The deliverables for the DKIM working group are:
* an informational RFC providing an overview of DKIM, how it can fit
into overall messaging systems and outlining potential DKIM
applictions
and future extensions
* an informational RFC presenting a detailed threat analysis of, and
security requirements for, DKIM
* a standards track specification for DKIM signature and verification
* a standards track specification for a DKIM DNS Resource Record
GOALS AND MILESTONES:
02/06 WG last call on DKIM threats and security requirements
05/06 WG last call on DKIM signature specification
12/06 WG last call on DKIM DNS Resource Record
12/06 WG last call on overview document
_______________________________________________
ietf-dkim mailing list
http://dkim.org