[dns-operations] AT&T DNS Cache Poisoning?

[Phil Regnauld]

Florian Maury (pub-dnsop) writes:
> Let's take an extreme example to illustrate:

	[...]

> Mallory wants to read Alice's emails. He manages to rent Bob "AMX". He,
> then, replays the old MX record set whose signature are not expired (the
> signature is still valid for 2 months) to Charlie, whose resolver is
> vulnerable to the Kaminsky hack.

	I use precisely this example in our workshops to illustrate why TTLs
	are included in the signatures, and why these are limited in duration.
	(Slight variation: old IP is rented by attacker to host a website that
	then does an SSL stripping attack, and Bob's your uncle[*])

	You still control the validity of the data in the cache, though you
	don't control the cache behaviour.

> If Alice could have revoked her signature on the previous MX RRSet, her
> emails sent by Charlie would not have been redirected to Mallory's server.

	Revoking = have short signature lifetime, publish new ones regularly
	that will be preferred by validators.

> One can tell "She should not have signed for a period that long". It's
> the eternal problem of zone survivability: the shorter the signature,
> the shorter the interval a slave server can serve data before it expires
> without signing the zone himself (which can be a problem if the slave
> server is administrated by a third party).

	It's an operational challenge, not a design one, and it remains:
	"polluting" caches with still-valid data is not cache poisoning
	(that data could have ended up in the cache in any number of ways;
	ceasing to publish signed data does not preclude it still being
	available somewhere).

	[*] No relation to to Alice's Bob.

	Cheers,
	Phil