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.
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.
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.
Here you break one of the better features of DKIM. The ability to
change the recipient when forwarding the message. The DKIM already
includes a date header and a expiry option. Why would a CRL not address
a replay problem?
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.
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.
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).
The normal practice based upon the IP address reputation would be to
report the abuse and expect a response. If the abuse continues and
there has been no response, then to protect those that subscribe to the
black-hole list, the IP address becomes listed. It is common for the IP
address space to be shared by many different domains, where this could
create collateral damage.
When the domain administrator is shown evidence of the abuse, they are
typically able to locate the account responsible. The difference
between Case 1 and Case 2 is whether the problem continues.
With DKIM, this becomes more difficult. The domain administrator may
locate the account creating the problem, but even disabling this account
will not prevent messages that are being replayed. It would be very
difficult to tell whether the reputation service was dealing with Case 1
or Case 2, as the domain may be unable to take effective action to
ensure abuse is stopped. Adding their domain to a black-hole list for
the next week will create a fair amount of collateral damage. A replay
problem due to a few zombies may be something that the typical domain
administrator would be at odds to avoid.
Just as Joe Jobs are a reaction to the use of IP address reputation
services, it is logical to expect that replay attacks will be a reaction
to domain name reputation services. I would also assume that spammers
would be clever and limit the number of repeated to messages to any
specific domain, and yet the aggregate of a specific message may still
be in the millions.
This is where the revocation-identifier becomes useful. An abuse report
should cause the identifier to be added to the domain's bad-list, where
the reputation service would then have immediate acknowledgment of a
corrective action. There would be no need to give the domain a bad
reputation to protect subscribers. If the domain is playing games, this
may wear thin the patients of the reputation service.
The revocation-identifier mechanism does not require locking the
recipient in the message, or even caring whether the abusive message is
the result of a replay attack. It simply does not matter. The
important point behind the revocation-identifier mechanism is the
expectation of immediate action is retained without mandating that all
domains issue user-keys.
There are many accreditation services that penalize clients. If you
trust the accreditation's management of bulk email providers, then this
becomes a pay as you go, but to those that manage the policies and
practices and ensure compliance.
-Doug
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim