ietf-mailsig
[Top] [All Lists]

Re: ] Replay attacks and ISP business models

2005-08-05 00:46:52


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

<Prev in Thread] Current Thread [Next in Thread>