On August 19, 2005 at 13:18, Eric Allman wrote:
First, by itself, DKIM is not an anti-phishing tool and is definitely
not an anti-spam tool.
Then the DKIM specification should be careful when refering to
such things. Since the current draft states that DKIM could assist
in dealing with phishing and spam, it either needs to remove the
statement(s) or mention how it can actually assist.
Since it appears people will infer that DKIM is designed to deal
with forgery (e.g. phishing), the specification must be clear about
the problem it is attempting to solve and its scope.
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.
Authentication has many levels and cannot be independent of the
roles various entities play.
This is why is my other posts I have tried to define the role domains
will play in message tranmission, separating the orginating domain
from subsequent domains.
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).
Unfortunately, the DKIM draft is not specific about this. The DKIM
draft mentions MUAs, and directly implies that MUAs can play an active
role in signing and verifying.
I am not sure if restricting DKIM to border MTAs (and systems in
between) is the way to go, but the DKIM specification should explicitly
state where DKIM applies and where it does not.
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.
I think here is where you get into some trouble. Accountability
has been mentioned numerous times, but it has not been defined
very well. There are different levels of accountability, and the
level of accountability is tied into the role a domain plays in the
transmission of a message.
In order for a reputation system to be built on top of DKIM, it
appears there is very useful value in knowing the role the signer
plays in the transmission of a message.
For example, the originating domain should have the greatest amount
of accountability while intermediate domains (forwarders, secondary
exchangers, mail lists) level of accountability is less, and may only
serve for traceability versus accountability.
It is counter-productive to hold a forwarding service to the same
level of accountability as the originating domain. This can be
cost prohibitive for a forwarding service, discouraging a forwarding
service from ever signing messages (assuming that such signing
is something DKIM should support).
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.
A reliable reputation service depends on accurate authentication
and the form of authentication being provided.
DKIM is a
pragmatic approach intended to be a "good enough" contribution to
solving a critical problem that is plaguing email today.
And what exactly is the "critical problem"? This ties into the
threat analysis work.
It appears the underlying problem is reliable authentication of email.
Without reliable authentication, it is hard to create reliable
reputation, accreditation, and other trust-type systems. For example,
without reliable authentication, and entity can be assigned a negative
reputation due to mis-identification. Without reliable authentication,
a malicious party can try to take advantage of someone elses positive
reputation (and/or accreditation) by exploiting inefficiencies in
the authentication system being utilized.
Due to scalability (and some other) factors, DKIM attempts to address
this problem at the domain level, leaving authentication at the mailbox
level to be a domain-specific problem or covered by other protocols
(e.g. S/MIME).
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.
Again, accountability is not absolute. With what is being said
about accountability on this (and previously ietf-mailsig) list,
it appears that only the originating domain should sign messages.
Entities that blindly sign all messages could be causing themselves
unneeded headaches for asserting accountability they do not want
to take.
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.
This is a dangerous assumption since any new legitimate business
or organization is assumed to be suspicious just because they are
new.
Since there can be problems with reputation systems, along with a
multitude of ways that reputation can be established, it is probably
better to not go into details about reputation systems when discussing
DKIM (which you mention in your post). I think it is sufficient
to state that DKIM can help facilitate reputation and accreditation
since it provides a reliable authentication system.
None of these
require direct association between the identity of the signing entity
and any header or envelope information.
I think the role of signers are important. IMHO, assigning the
same level of accountability on any signer ignores how email systems
operate.
IMHO, even mentioning accountability wrt DKIM could kill it. Why?
Because you then have to discuss the level of accountability the
signer takes, and if it is a fixed level of accountability, this can
discourage many to adopt it. How accountability is enforced is not
a trivial manner and should not be part of DKIM.
It is clear that something like DKIM can help facilitate accountability
via reputation, accreditation, and/or whatever. All this can be
done since DKIM will hopefully provide an acceptable, good-enough
authentication framework for email.
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.
Agreed. Accountability should be in this list also. It would be
impractical to try to define accountability in the DKIM specification
since accountability implies reprecussions and all the actions who
have mentioned.
Everything you have said can be achieved if DKIM not only provides
a cryptographic signing mechanism for email, but allows the role of
the signer to be clearly defined.
If DKIM is to be restricted in only supporting the role of originating
domain, then discussion about signing by intermediary entities should
be dropped and explicitly excluded as outside of DKIM's scope.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org