On Aug 6, 2005, at 11:07 AM, John R Levine wrote:
No, because it depends on the mental state of "spammer" and
"accomplice".
How interesting that you think we cannot describe an attack unless we
know the mental state of the attacker. I really don't know the
mental state of the spammers who send most of the spam I receive,
does that mean I cannot begin to describe how they sent the spam? If
victims of a bank robbery cannot tell the police that the bank robber
did it to feed his family or just to be rich, does that mean the
police have to ignore any details of the robbery given to them by the
victims?
Here's section 9.5 with minor edits to make its
terminology more consistent with other RFCs:
9.5 Replay Attacks
In this attack, a user sends a message to be distributed to a
mailing list, which results in the message being signed by the
originating MTA. The mailing list resends the message,
including the
original signature, to a large number of recipients, possibly by
sending the message to many intermediate exploders that act as
MTAs.
The messages, not having been modified by the mailing list, have
valid
signatures.
Actually, I was thinking that zombies would be the primary vehicles
for the replay. This mailing list centric view of the attack would
lead people to believe that it is the only method. I much prefer the
current wording.
On Aug 6, 2005, at 5:04 PM, wayne wrote:
First off, that implies that the large ISPs, email hosters, or anyone
who can have spammers easily sign up for their services, will need to
do per-user DKIM keys.
For domains with more than a few users, yes.
Elsewhere on this list, I've seen it argued
that per-user keys will be rare.
Technologists have a fairly poor track record with predicting the
future, especially with regard to how others will use technology.
Certainly, if every
yahoo/aol/hotmail/etc user had their own key, the amount of DNS
caching is going to be very significant.
Secondly, you have to do something about the DoS attack on user
accounts of victims by having bad people do lots of queries to
trigger the "this must be spam" detection systems and have victims'
accounts shut down.
Good point. But the revocation ID suffers from the same problem.
Back in Jan 2004, when I posted my first thoughts on DK, I mentioned
that Razor/DCC/Pyzor could detect replayed messages, but that means
that
in order to make DKIM work, you have to also use another new
protocol. While Razor/DCC/Pyzor try to do their own caching, you are
still basically requiring a per-email call-back to verify whether the
email is bulk. Then you need to do something to decide if the email
is unsolicited, because simply being bulk isn't bad.
Personally, I use both DCC and pyzor on a per-email basis as part of
my spamassassin setup. I don't have any objections to this, and I
think DKIM would be great because the detection rates on DCC/Pyzor
would be very high. However, I've heard a lot of screaming from many
different sources about how how callbacks are unacceptable. YMMV.
It would seem that if they become acceptable just to prevent replay
for DKIM, then there are a host of other options that should be
acceptable.
-andy