On Aug 5, 2005, at 9:35 AM, Andrew Newton wrote:
On Aug 3, 2005, at 6:38 PM, Tony Finch wrote:
One thing that hasn't been mentioned yet is the idea of "soft"
defences
against replay attacks. For example, a suitable reputation or
revocation
service could include a rate-limiting system, so that as well as
pass and
fail they could return an intermediate result that would translate
into an
SMTP 450 response. This could be used to slow down a bulk mailing
until it
becomes clear whether it's good or bad.
Zombies spreading the load around to different points of injection
could get around these "soft" defenses. And given the lack of
clarity in being able to describe the problem we are trying to get
DKIM to solve (as witnessed in the BoF), I find relying on less
well-defined mechanisms to shore up some of the issues with DKIM to
be unpalatable and giving of an incomplete story to observers.
DKIM needs to have a good story regarding defense of replay.
However, I'm now less convinced of Doug's revocation ID idea. It
almost seems that replay can be detected just by monitoring the
number of queries against a user key. This would be especially
true if the other key retrieval methods are used for user keying.
The use of the DNS query would provide some warning especially with
respect to the revocation-identifier. There would be much less to
differentiate abuse with a common key on a large domain. I assume
you are suggesting that per-user keys would be a solution for large
domains, which seems to be a reason you now indicate DKIM
specifically protects the mailbox address. While this could be
attempted, it would not be always true. When this is true or not
true would not be apparent. I would say it is safer to declare that
DKIM provides an accountable domain. Yes, key servers would better
support per-user keys. Will DKIM get per-user keys off the ground.
Is that the goal of DKIM?
I would also say that for DKIM to have a benefit, finding an
accountable domain is not enough. This domain must be able to take
positive action to stop abuse. This was the idea behind the
revocation-identifier.
-Doug