Re: [ietf-dkim] Replay isn't the problem, spam is the problem
2005-08-09 06:43:13
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
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] What's a replay?, (continued)
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Amir Herzberg
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, John R Levine
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Amir Herzberg
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, John R Levine
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Douglas Otis
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem,
Amir Herzberg <=
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Douglas Otis
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Michael Thomas
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Hector Santos
- Re: [ietf-dkim] Replay isn't the problem, spam is the problem, Douglas Otis
- Re: DKIM implementations SHOULD support replay protection (was: Re: [ietf-dkim]Re: Replay attacks and ISP business models, Dave Crocker
- Re: [ietf-dkim] Re: Replay attacks and ISP business models, Amir Herzberg
[ietf-dkim] Re: Replay attacks and ISP business models, Douglas Otis
|
|
|