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

[Florian Maury]

Thank you for your answer, Roy.
Here follows my comments.

On 29/10/2012 12:54, Roy Arends wrote:> I did not say that. I asked
"DNSSEC does not defend against the Kaminsky hack?".

I thought it was some sort of rhetoric question. My apologies.

>> AFAIK, DNSSEC does not possess any revocation mechanism (an expiration
>> mechanism does exist but I am really talking about _revocation_).
>
> Sure, CRL's are mostly only valid for 24 hours. So the revocation
granularity for certificates is not real time and might have at least a
86399 second delay. If you'd want to beat that with DNSSEC, re-sign at
least twice a day :-). I'm trying to argue that times can be 'gamed' to
match CRL requirements.

OCSP is a real time certificate checking method. Only realtime signing
(Phreebird, etc) of TLSA records can match that, I think.
Some say "what's the matter anyway? Neither CRLs nor OCSP are checked in
the real world.". I often answer that X509 have the merit to possess an
already-designed revocation mechanism, which DANE cannot claim to have yet.
But maybe this should be discussed off-list or on DANE WG mailing-list.
Sorry.

>> I have to admit this attack scenario is far-reached, as most
>> DNSSEC-validatating servers do implement SPR and some even implement
>> 0x20, but there is still the problem of middle boxes "un-randomizing"
>> source ports.
>
> To me, DNSSEC protects the dns cache against Kaminsky's hack. It is
not cache poisoning if you inject a cache with valid data.

Naming convention problem then. My bad.

Can you tell me how do you name a record no longer served by
authoritative servers (removal is assumed to be a deliberate move) but
whose signature are still valid?
These "pseudo-valid" records can still be "injected" via a Kaminsky hack
or MITM attack, which can be occasionally of concern.

Best regards,
Florian Maury