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

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




Better late than never i guess.

In message <199607271950.MAA00914@imo.plaintalk.bellevue.wa.us>, Dennis Glattin
g writes:
>
>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.
>
I believe this is covered by mandating that any implementation should
be able to handle at least 2 valid KEY records for each name (intro of
section 3).

>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?
>
Lock em up and post a marine with an M16A2 outside the door ?
Seriously tho, the draft is concerned with the technological aspect of
security, not with the...social. No matter what key management one
has, people will always be a potential leak/weak link/whatever.

>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.
>
I fail to see what this has to do with DNSSEC. Clearly, if a host is
compromised, the assumptions on which IPSEC was built no longer hold.
Besides, I still don't know why breaking into a DNS server (maybe a
root ?) would somehow give you divine powers over the zone data; the
private key is supposed to be offline.

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

Get the key through DNS, and this key is signed by the old key (if
this is a normal rollover) and by whoever signs the keys for that
root. Again, i assume that even the root keys are signed by one or
more other "trusted" authorities (maybe IETF, ISOC etc should
create a key just to sign root keys, which shouldn't happen all that
often).

>* A compromised server could redirect the address of the
>  trusted key repository, resulting in a schizophrenic
>  Internet.
The old key is still in effect, so the server can't fake data.

>* 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.
See above.

>* 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!
That is true. However, also easily noticeable.

>* How about increasing key sizes too.
>Morris did nothing compared to the damage possible with
>DNSSEC.
>
Expand on this ?

>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.
>
Indicate to the user that this might not be as secure a lookup as he
might think maybe. Let me ask something else in return.
In a mixed IPSEC-using and not Internet, what is someone who wants to
securely connect to some remote host that doesn't use IPSEC going to
do ?

>(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.)
>
But it is not a totally impossible task either. There are a few
approaches that will accelerate deployment of DNSSEC.

>
>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.
>
Expand on this ?

>
>Does DNSSEC add value to IPSEC? Maybe. I believe that for
>the next several years its value is limited.
>
There probably are alternatives, but they (probably) won't scale as
good, and will require some sort of new infrastructure.
-Angelos