Re: [dnsext] historal root keys for upgrade path?

[Edward Lewis <[e-mail]>]

At 10:06 -0500 1/26/11, Paul Wouters wrote:

>This means with ONE original trusted key, the device can climb up to the
>current root key in a trusted way. Adding X.509/CA chains solves nothing
>and adds more complications.

I've been opposed to DNSEXT developing a solution to this problem 
from the start.  Now, here's yet another reason.

As much as it would appear that adding a X.509/CA-derived mechanism 
would redundantly add to the already existing DNS mechanisms ad DNS 
admin would have, adding a DNS-based update mechanism would add to 
the exiting SysAdmin mechanisms a Systems admin would have.

Reading through this thread adds even more to the reasons why I think 
this topic is a non-starter.  At first was that this proposal 
effectively extends the key effectivity period of the zone keys 
beyond the DNS need for it.  Now I see the impracticality of having 
remote machines having to navigate a variety of network security 
obstacles (such as firewalls) to phone home for security data.  I'm 
not encouraged.

More over, when it comes to something as sensitive to security, I'd 
rather have the configuration done on the in-office desk (or in a 
staging area within our own data center, etc.) of an admin than in 
remote rackspace, with or without remote hands involved.  This is a 
general rule, I am not running an operations/security team.  Once on 
the desk, normal sysadmin tools and techniques apply.

(We have had our share of customs issues shipping equipment we built 
locally and then deployed remotely.  That's another issue.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

With a week old newborn at home, I've discovered that the only 
difference between him and me is that I have to go to work daily. 
That's not fair!  Ma!