On October 29, 2005 at 06:44, Eric Rescorla wrote:
S 5:
One of the most fundamental bad acts being attempted is the delivery
of messages which are not authorized by the alleged originating
domain. As described above, these messages might merely be unwanted
by the recipient, or might be part of a confidence scheme or a
delivery vector for malware.
This seems to me to be too concrete. At a meta-level, the bad
act being attempted is the delivery of messages which the receiver
doesn't want to see (see Section 2 again).
Only the receiver knows what they want and do not want to see.
The bad act is the deliberate deception by the sender upon the
recipient to avoid accountability and/or obtain a false sense of
trust in order to entice the recipient to perform actions based on
that false trust.
A spam message does not mean that any identities are being spoofed.
But doesn't this effectively say "DKIM (or any sender signing scheme)
doesn't work against attacks that attempt to involve impersonating
a specific source address"? What class of specific impersonation
attacks does this technology actually work against in practice?
"Exact" domain spoofing. I.e. There is a desire to at least deal
with cases to avoid unauthorized use of an exact domain. Look-alike
attacks are a much more difficult problem since human factors are
more involved.
S 5.2.3:
I don't see how you can reasonably deal with replay attacks
by revoking the key that was used to sign the message. This
enables a trivial DoS attack on any message sender--just
get some messages from that sender and generate some replays.
Key revocation is also a heavy method for dealing with replay, and
may be impractical for many when a single private key is used
to sign messages for multiple senders. Revoking a key can invalidate
many legitimate messages.
Doug's opaque ID method is more suitable for revocation of a known
message. It is still TBD, FMPOV, if the opaque ID is still sufficient
enough to deal with replay since the window of opportunity may still
be large enough that when revocation is done: the damage has already
been done.
Again, I realize that the DKIM designers have chosen not to
handle replay, but that doesn't mean there's no way to handle
it with a server-based signing scheme. This seems like exactly
the kind of issue that a threat analysis should cover.
Replay is a major problem for DKIM. I agree that it needs to
be addressed. If not by DKIM itself, at least strategies spelled
out on how it can be handled.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org