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

[Amir Herzberg]

Douglas Otis wrote:
> On Tue, 2005-08-09 at 01:17 +0200, Amir Herzberg wrote:
> 
>>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.
>>
>>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.
> 
> I agree with John about the fallacy of this statement.  Repeated
> messages are not, by themselves, indicative of abuse.  There are valid
> reasons a message may be replicated.  Without getting into the details,
> detecting abuse does not depend upon seeing repeated messages.  Every
> abusive message can be considered to stand on its own.
It is not the repeated messages that are the proof of abuse. The proof 
of abuse is the _content_ of spam messages, together with the signature 
proving a particular entity authorized sending this spam. A signature 
without replay protection allows sending the same message to many 
recipients, but with the proof of abuse will be the same as if the 
message was sent to single recipient - we can't penalize based on the 
number of recipients, and definitely we can't compensate specific 
recipients whose resources were consumed.
> 
>>Replay protection allows automated compensation management: a signed 
>>spam automatically becomes a `certified check` crediting the recipient.
> 
> This makes little sense.  The signature clearly indicates who is the
> accountable domain, but how would there be credit given the recipient?
> Are you talking about paying the recipient when receiving spam?  Good
> luck dealing with stolen credit cards and false identification, which
> would surely be dark side of such a scheme.  Even charging the cost of a
> postage stamp for first class mail in the recipient's country, and
> having the postal service collect the fees would be a monumental task.
I agree that the schemes you considered above are not very good. 
However, I also believe correct, viable solutions are possible. Now, if 
you are interested, we can discuss such possible solutions, but I don't 
think DKIM charter should cover this (or this mailing list used for this 
discussion). OTOH, DKIM should provide the basic machinery to allow 
reputation, accrediation and compensation schemes to use it.

> Here you break one of the better features of DKIM.  The ability to
> change the recipient when forwarding the message.  
I do not propose that DKIM should specificy receivers MUST discard 
messages received without replay protection (and recipient 
identification). I just propose we give recipients the ability to 
distinguish between messages with replay protection and recipient 
identification, and messages without these capabilities. So forwarding 
still works, but degrades the security of the message - to the level we 
have with DKIM without replay protection. What's the problem?

 > The DKIM already includes a date header and a expiry option.
> Why would a CRL not address a replay problem?  
CRL is a mechanism to revoke certificates, how is it relevant?
...
> How does one rate limit when a message can be copied and sent through
> any server where the recipient can also be changed?  I assume you want
> to remove the feature where the recipient field can be changed.

No. A mail server can rate control the messages that it sends. It cannot 
control what happens to them later. So that caps the responsibility of 
the server, for reputation/accreditation/compensation services. 
Recipients can still decide, of course, they are willing to accept 
messages without replay protection, possibly based on their source (e.g. 
a particular trusted, moderated mailing list).
-- 
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