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

[Roy Arends]

On Oct 29, 2012, at 8:26 AM, Florian Maury wrote:

> Hi,
> 
> On 28/10/2012 22:58, Roy Arends wrote:
>> On Oct 28, 2012, at 7:40 AM, bert hubert <bert.hubert at netherlabs.nl> wrote:
>> 
>>> On Sat, Oct 27, 2012 at 11:43:40PM -0700, David Conrad wrote:
>>>>> It appears that source port randomization works. 
>>>> 
>>>> Was there ever any doubt?  The question wasn't (isn't?) whether source
>>> 
>>> Yes, people used the Kaminsky hack as a way to push DNSSEC. 
>> 
>> DNSSEC does not defend against the Kaminsky hack?
> 
> 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.".

I did not say that. I asked "DNSSEC does not defend against the Kaminsky hack?". 

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

> 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
> signature is still valid (even if is has been removed from the zone (in
> an attempt to revoke it)).

You're in application space. To me, DNSSEC is expensive error detection. If DANE folks want to use DNSSEC for an alternative CA path, they should understand the consequences (which, btw, I think they mostly do). But… see above for a recommendation.

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

Roy

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