[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ] Replay attacks and ISP business models
On Aug 3, 2005, at 6:38 PM, Tony Finch wrote:
On Mon, 1 Aug 2005, Jim Fenton wrote:
- There was a suggestion of a "revocation ID" that could
optionally be part of
the signature. If present, the verifier would need to query the
originating
domain (DNS again, probably...) to see if there is a record
indicating that
the given revocation ID has indeed been revoked (absence of a record
indicating no revocation). ISPs would potentially apply a different
revocation ID per customer. This warrants further study; if DNS
is used for
this, we need to think about both the transaction load and the
amount of
negative caching that would need to be done.
The scaling issues here are similar to per-user keys, so I won't
repeat
myself.
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.
-andy