[ietf-dkim] what DKIM is --- a personal perspective

[Eric Allman]

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