[ietf-dkim] Replay isn't the problem, spam is the problem

[Amir Herzberg]

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