[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNSSEC for IPSEC? -- or, how to exploit DNSSEC


There are several problems with DNSSEC that make it ripe
for exploitation. I have included some of my thoughts in
this message and are the basis of why I feel it is not a good
idea to mandate connectivity between DNSSEC and IPSEC --
at least for the near future.

The holes in DNSSEC are not confined to the extensions
themselves rather they include practicality of DNS
management and operation.

The DNSSEC extensions document little addresses the
issue of key roll-over. Consequently, it is difficult to
differentiate between an alarm be sounded as a result of a
root server compromise and the attacker replacing its
key pair and one sounded in response to legitimate key
roll-over. The document mentions the issue of cross
signatures but does not indicate their role. I have not
found a document that addresses these issues.

The DNSSEC extensions document recommends a procedure
for server private key management. That is all it is: a
recommendation. Is that how the entities managing the
root servers will manage them? Moreover, how are the root
servers themselves secured? How will the weakest link,
the people, be managed?

Administrators tend to aggregate service classes to
"ease administration". The same set of procedures and
functions applied to one service are applied to all
members of the aggregate. Therefore, it is highly
probable that a technique used to penetrate one root
server is a successful avenue to another. Consequently,
it is possible to create a believable web of trust across
compromised servers.

When a parent zone changes its key, all its siblings will
have to be updated (hmm, what is the number of zones under
COM?). How will the administrators of those zones get the
new key? How can they trust what they are getting? Suppose
for a moment that a root server is compromised. Oh what
chaos one can create.
* A compromised server could redirect the address of the
  trusted key repository, resulting in a schizophrenic
  Internet.
* If bogus responses are believable, the cache of tens of
  thousands of servers will quickly be polluted. To clean
  them, those servers will have to be rebooted. The result
  is something close to rebooting the Internet.
* The root server can reduce TTL values to their minimum,
  resulting in other servers often reloading the RRs
  and recomputing SIGs -- watch their CPU load jump!
* How about increasing key sizes too.
Morris did nothing compared to the damage possible with
DNSSEC.

Glue data is not signed. Therefore, a server could
redirect requests for nsa.gov, cia.gov, and
whitehouse.gov to eff.org. If eff.org is not secure I
suspect many recipients will believe the responses,
i.e., until they get there. Why? Because for many years
DNSSEC aware resolvers are going to have to live within
the current, DNSSEC unaware, Internet.

It is easy for a DNSSEC aware resolver to believe a
response from a DNSSEC aware source; however, in a
combined DNSSEC aware and unaware Internet, what is a
resolver going to do when it gets a response from a DNSSEC
unaware source? Ignore it? To do so would limit
resolution breadth.

(Bear in mind that no body has the authority to impose
DNSSEC across the Internet. Therefore, the issue of
DNSSEC aware resolvers having to figure out what to do
with responses from DNSSEC unaware sources will not go
away.)


What kind of chaos can be created if the server's code is
replaced? One thought is to always clear the AD bit in
responses.


Does DNSSEC add value to IPSEC? Maybe. I believe that for
the next several years its value is limited.


-dpg
References: