[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ] Replay attacks and ISP business models
On Mon, 1 Aug 2005, Sam Hartman wrote:
> I'd like to make sure the issue of replays is covered at the BOF and
> is something the IETF community considers carefully before approving a
> charter for this working group.
> I'd like to ask us to think particularly about the impact of this
> attack on business models of medium sized ISPs. Fundamentally few
> people are going to block all mail from AOL,, Yahoo, Gmail or the
> like. However smaller ISPs have been subjected to a wide variety of
> problems with various blackhole lists.
> It's not clear how you could maintain a reputation while still
> defaulting to providing service to anyone who wants an account.
I agree that this needs to be addressed in the security considerations
section, but I don't think replay attacks are a problem for DKIM itself.
DKIM is providing message origin authentication and message integrity, and
replay is not an attack on either of these services. Another way of
stating this is that DKIM by itself does not completely address spam; it
depends on reputation services for that, and replay is an attack against
What DKIM needs to do is provide a sufficiently fine-grained idea of
identity so that reputation services are not forced into causing
collateral damage. Fortunately that's already the case: you can key the
reputation lookup off the signer's identity i= rather than the domain d=,
so the ISP's reputation need not be tainted if only a very small
proportion of its customers behave badly. Doug's suggestion of using a
revocation ID is also relevant here.
There is also a layer 8 defence: ISPs could use something like the
Spamhaus registry of known spam operations to vet customers; this could be
automated by keying lookups off their credit card numbers (or a hash of
their credit card numbers to avoid exposing them). This would shift the
problem to free email providers (or to identity hijacking, but that's a
result of more fundamental security problems).
f.a.n.finch <dot@xxxxxxxx> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR