[ietf-dkim] what DKIM is --- a personal perspective
2005-08-19 13:21:10
I want to emphasize that this is my personal opinion of what DKIM is
and how it fits into a larger system, and also what DKIM is not. It
does not (necessarily) represent consensus from my co-authors. But I
hope that this summary may help us come to some sort of convergence.
First, by itself, DKIM is not an anti-phishing tool and is definitely
not an anti-spam tool. It is not intended for direct end-user use.
It is not intended to stand by itself. It is designed to
authenticate at the domain administration level rather than the user
level, although there are some hooks designed to prevent misuse of
the user (local) part for a limited number of common situations. It
is not intended to replace existing systems such as S/MIME or
OpenPGP, which provide a higher level of assurance (in particular,
authenticating individual users) but without transparency to end
users in most cases. Also, these are usually end-to-end protocols,
and DKIM is designed to be used between the boundary of the sender
and the boundary of the receiver with possible intermediate MTAs (and
yes, I do realize that S/MIME and PGP can be used in this mode, and
that DKIM can be used end-to-end, but that's not the primary design
goals of any of these examples).
DKIM is a protocol enabling some entity to assert accountability for
the message. "Accountability" doesn't necessarily have to be
attached to authorship of the message, the content of the message, or
any header fields of the message, because the primary point is simply
to create an authenticated identity of an accountable entity to which
a reputation can be attached. The entity is a domain, not an
individual address. Reputation is a critical part of an overall
anti-spam, anti-phishing system but is intentionally outside the
purview of the DKIM base specification because how you do reputation
is fundamentally orthogonal to how you do authentication. DKIM is a
pragmatic approach intended to be a "good enough" contribution to
solving a critical problem that is plaguing email today.
Conceptually, once you have established an identity of an accountable
entity associated with a message you can start to apply a new class
of identity-based algorithms, notably reputation. Reputation might be
local (allow mail signed by domains listed in my address book or some
other allow list) or bilateral (big senders and big ISPs could create
agreements), but in the longer term reputation is likely to be based
on community collaboration or third party accreditation.
Collaborative reputation is in some sense self-healing: if a signing
identity gets a reputation for forging mail (i.e., sending mail
claiming to be from someone it's not and is not authorized to act on
behalf of), it will get a bad reputation, and this will mean that
mail signed by that entity will be less likely to be accepted; in
particular, association between the signing identity and some header
field identity is a good thing but not necessary for DKIM to succeed.
If that signing entity gets a reputation for sending spam or
phishing, it will get a bad reputation. If a signing entity has no
reputation (i.e., is new) then it will be treated with suspicion,
since that's highly likely to be a new spammer domain. None of these
require direct association between the identity of the signing entity
and any header or envelope information.
The addition of a Sender Signing Policy can provide a secondary use
that is more direct. The SSP only needs to be consulted if the
message is not signed with a valid signature or if the Origination
Address (OA, defined as the identity in the From header field, or, if
and only if there are multiple identities in the From header field,
the identity in the Sender header field, as defined in RFC 2822) is
not clearly associated with the signing entity. The domain of the OA
is the domain that is queried for a SSP, creating a fundamental
association with the header. Such a SSP might say which entities
are authorized to sign on behalf of the OA domain, whether that OA
domain signs all messages, and so forth. This permits a verifying
site to make quite sophisticated delivery decisions.
This information is intended as input into a larger protection system
that may include quarantining, content scanning, challenges (perhaps
at the SMTP level, should an extension be defined), or whatever a
verifying site would like to use. For example, a site might have a
policy that authenticated mail with good reputation or on an allow
list would be immediately delivered if the signing identity matched
the OA or was explicitly authorized by the SSP associated with the
OA, and would otherwise be quarantined; all unauthenticated mail and
authenticated mail with unknown reputation was carefully content
scanned and/or challenged; and authenticated mail with a bad
reputation was discarded.
It would be inappropriate to force the DKIM specification to also
include how reputation, scanning, challenges, or quarantining would
be performed because they are fundamentally different tasks. A
single reputation system could work using multiple methods of
authentication, including proposals such as SIDF; similarly, a DKIM
authentication system could be used to establish an identity used by
multiple different accreditation and/or reputation systems.
In summary, I believe that (a) DKIM is useful; (b) it has valid use
even without associating the signing identity with the header; (c) it
fits well with but is orthogonal to other systems, notably
reputation/accreditation; (d) the definition of those other systems
should not be bundled with DKIM; and (e) independent definition of
such systems should begin immediately. A truly minimalist approach
would even separate SSP, but I believe that SSP is fundamental enough
that it belongs as part of an early specification (but I'm not
claiming that the current SSP draft is good --- I know that it's
missing a lot, notably delegation of authorization to sign for
another domain, and it generally needs a lot of work).
eric
_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [ietf-dkim] what DKIM is --- a personal perspective,
Eric Allman <=
|
|
|