On Tue, 9 Aug 2005, Hallam-Baker, Phillip wrote:
I think the real distinction here is not between per-user and per-domain
keys, its between persistent keys that provide for non-repudiation and
ephemeral keys that allow for limited term verification.
The DKIM key retrieval mechanism is only designed to do ephemeral keys.
Extending it to do persistent keys or non repudiation is a very bad idea
and would require the DNS to become a PKI. Even if you have DNSSEC
deployed you will not change this.
Phillip has brought up a key word - "repudiation" - which I think might
help focus the discussion.
The attack that we are worrying about is bulk-resending of an undesirable
signed message. What we want to be able to do is (1) detect when this is
happening and (2) stop it before it goes on too long. Step (2) is
effectively repudiation of the signature. This implies that
non-repudiation is not a desirable feature of DKIM!
There are a couple of difficulties with this defence. Step (1) implies
some kind of value judgment on the desirability of the message, which
distinguishes it from mailing lists which bulk-resend desirable email.
Step (2) implies that the elapsed time between the start of the spam run
and the reputiation of the signature (including the time for a human to
become aware of the problem and examine the message) must be short.
This isn't easy, though it has been implemented a couple of times (Razor,
Pyzor). Note that DCC doesn't include a human in the loop to decide the
undesirability of messages that are to be stopped; it measures bulkiness
only. The other thing to note is that all three of these systems are
Internet-wide. Specifying that something like this must be implemented on
a per-domain basis is probably over-ambitious.
--
I'm not sure why Phillip thinks DKIM requires a full-on PKI. Isn't
publishing and removing short-lived keys in the DNS sufficient? Key
removal provides a simple repudiation mechanism, if the TTLs are suitably
short.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim