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

Paul Wouters paul at nohats.ca
Mon Oct 29 12:33:55 UTC 2012


On Mon, 29 Oct 2012, Florian Maury wrote:

> As a matter of fact, I think it does not. It only limits the impact of
> some attack scenarios. Hopefully, those thwarted are the most
> devastating, in term of integrity, but if I'm correct you cannot
> honestly assert "DNSSEC solve the Kaminsky problem. Period.".
> AFAIK, DNSSEC does not possess any revocation mechanism (an expiration
> mechanism does exist but I am really talking about _revocation_).

The kaminsky attack has nothing to do with revocation. DNSSEC solves the
kaminsky attack which relies on unsigned spoofable data.

> 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

*BUZZER*

http://tools.ietf.org/html/rfc6698#section-1.3

    This document defines a secure method to associate the certificate
    that is obtained from the TLS server with a domain name using DNS;
    the DNS information needs to be protected by DNSSEC.

See also:

8. Security Considerations


    The security of the DNS RRtype described in this document relies on
    the security of DNSSEC to verify that the TLSA record has not been
    altered.

TLSA records that are not protected with DNSSEC, MUST NOT be used. If
implementations do this anyway, they are broken.

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

Patience, my grass hopper.

Paul



More information about the dns-operations mailing list