ietf-dkim
[Top] [All Lists]

[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>