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

Florian Maury pub-dnsop at x-cli.com
Mon Oct 29 13:36:43 UTC 2012

On 29/10/2012 13:33, Paul Wouters wrote:
> The kaminsky attack has nothing to do with revocation. DNSSEC solves the
> kaminsky attack which relies on unsigned spoofable data.

I may be the only one worried about replayed signed data, after it is
removed from authoritative servers.
Let's take an extreme example to illustrate:

Alice rents Bob a server called "AMX" and uses this server as a MX for
her domain. The MX record is configured with a TTL of 1 day and the
record set is signed for 3 months.
A month later, Alice's activity has grown exponentially, and the server
has become undersized for her mailing activity, so she rents Bob a
larger server, "BMX". She configures "BMX" to be her new MX and give
back to Bob the "AMX" server. The new MX record set no longer contains
the "AMX" server.

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. When Charlie will want to send an email
to Alice, he will find in its cache the replayed record set (because the
signature is valid, the DNSSEC-validator has no reason to reject it) and
will send his email to Mallory.
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.

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).

>> This lack of revocation mechanism can be a problem for some usage of
>> DNSSEC, as in DANE where usage type 2 or 3 induce a new risk: a cache
>> could be poisoned via a Kaminsky attack with a TLSA record whose
> TLSA records that are not protected with DNSSEC, MUST NOT be used. If
> implementations do this anyway, they are broken.

Absolutely. I was talking about valid DNSSEC-signed TLSA record sets
replayed after their removal from the zone but before their signature

>> I would be happy to be proven wrong. I'm only a not-so-young padawan,
>> after all ;)
> Patience, my grass hopper.

Thank you,

Florian Maury

More information about the dns-operations mailing list