Subject: Re: DNS Blackhole attack

From: Alex Bligh <[email-masked]>
Date: Sun, 06 Mar 2005 22:49:58 +0000

--On 06 March 2005 19:26 +0000 Paul Vixie <[email-masked]> wrote:

> the case where the glue is MIM'd reduces to the case where your packets
> are destroyed by loss or congestion,

For my education: Why does an attack which involves *introducing* a
spurious glue record (in vanilla DNS) reduce (in DNSSEC) to an attack where
packets are destroyed by loss or congestion (which I agree in DNSSEC is
insoluble)?

IE if it reduces to a common denominator, what is the (unpreventable)
attack on DNSSEC which produces the same result as MIM glue insertion in
vanilla DNS?

My (as yet uneducated) read had been that both were susceptible to DoS (in
the truest sense) attacks due to packet loss, but that while vanilla DNS
could suffer from injection of false information, the worst that could
happen in a DNSSEC world is that participants could be prevented from
receiving updated information or notification that old information was out
of date. Should I be removing my ever-decreasingly-rose-tinted specs?

Alex

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Johan Ihrén <[email-masked]>
Date: Mon, 7 Mar 2005 03:01:18 +0100

> attack on DNSSEC which produces the same result as MIM glue insertion 

I think you misunderstood Paul.

His point is that with DNSSEC MIM'd glue eventually results in a 
response that doesn't validate and hence is discarded, which is 
basically the same outcome as the response packet being lost in 
transit. What DNSSEC cannot prevent is the spoofing as such, it can 
only help detect when it is happening.

There is no unpreventable attack on DNSSEC that will produce the same 
result as MIM glue insertion in vanilla DNS (i.e. forged data being 
accepted as valid).

> of date.

Signed glue is a red hering. DNSSEC isn't about securing server 
identities, it is about securing data.

As most of you know for a signed delegation the referral will contain 
NS RRset for the child + DS for the child + RRSIG(DS) + possibly some 
glue. The RRSIG(DS) enables the validator to verify whether the data 
from the child is authentic or not regardlesss of whether it arrived 
from the right servers or not. I.e. it will work just fine even if the 
glue is spoofed as long as the bad guy serves data that validate.

For an unsigned delegation there will be no DS nor RRSIG(DS) and hence 
no such protection for the child. In this case the semantics and risk 
of spoofing fall back to be the same as for standard DNS. This is not 
surprising, as an unsigned delegation is a statement of the child not 
having requested the data protection that would come from the 
delegation being signed. I.e. either the child isn't DNSSEC capable or 
it is DNSSEC capable, but, for whatever reason, does its own trust 
anchor distribution.

> Should I be removing my ever-decreasingly-rose-tinted specs?

No.

Regards,

Johan