John R Levine wrote:
The point is that replay protection is _critical_ for automated
reputation and compensation mechanisms.
People keep saying this as though it's obvious. I must be unusually dim
today because it's not obvious at all to me, and doesn't seem to have been
obvious to designers of previous signature systems.
You are right; I did not explain _why_ replay protection is critical
(for automated reputation and compensation management).
Replay protection allows automated reputation management, since it
provides a signed proof of misconduct. Of course, we get proof of
misconduct also without replay protection, e.g. by showing the domain
signed spam. But replay protection allows different penalty for
sending/allowing a single spam to single recipient, vs. sending bulk
(identical) spam to many recipients.
Replay protection allows automated compensation management: a signed
spam automatically becomes a `certified check` crediting the recipient.
I can't put all details here (but can refer you to papers if you like);
in any case, this is _not_ part of DKIM functionality. But DKIM _can_
provide the underlying mechanism for both automated reputation and
automated compensation, provided `replay protection` or more correctly
recipient identification is allowed (as an option).
Now to your other questions...
Do you check CRLs on S/MIME mail? (They are turned off by default in many
MUAs.) PGP seems to have no way to deal with replay at all. Is that why
it hasn't caught on?
I don't think this is a problem with PGP, and CRLs are not sufficient as
an anti-replay mechanism. But of course anti-replay is easy, e.g. if the
signed text includes timestamp and recipient identification.
Doug has offered the only scenario so far of a replay attack, which is
very helpful to figuring out what the threat is. His scenario boils down
to one of a domain's users being a spammer, which would be a problem
whether or not his spam was being remailed.
The scenario where `one of the domain users` is a spammer, or
(temporarily) controlled by spammer (e.g. Zombied), is almost the most
basic scenario we need to consider. Domains should be able to control
the risk from a single customer (temporarily) being `bad`. The basic
solution is rate limiting. For this to work, the domain should be able
to control the `rate`, i.e. the amount of spam per user. Replay
protection is essential. Without it, suppose a reputation manager (e.g.
black list) gets a lot of complaints on a small or medium sized email
domain V. Without recipient identification, it may be hard to
distinguish between the following two cases:
Case 1: V is a Vicious domain: spammer or spammer-friendly.
Case 2: V is an innocent Victim. It only signed a single message of one
of its customers (e.g. Zombied).
--
Best regards,
Amir Herzberg
Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI:
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages:
http://AmirHerzberg.com/shame
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim