At 17:03 +0200 4/21/09, Florian Weimer wrote:
* Edward Lewis:
This comes from the observation that the contents of the database
sourcing the zone (whether a commercial-like database or a vi'd file)
are more critical than the private key. (If) They are sufficiently
protected and I'll just keep the private key behind the same
fortifications. So, what does an HSM add?
I think the general idea is that if you have to edit your zone because
it was tampered with, chances are that nobody will notice (or
everybody will attribute it to routine maintenance). If your key is
compromised and you have to replace it out of schedule, you might have
got some explaining to do. 8-)
Of course, this isn't a strong argument in favor of HSMs.
(Changing the subject to "HSMs" because this is more about that than
the draft.)
Before the thread goes too far, I should say that I'm thinking of
this as an operator of a zone that delegates to other entities.
In such a situation, diddling inappropriately with the database means
"*some*body *will* notice" and that somebody is "above my
management." (I.e., customers.) Diddling with the private key is
something I only need to raise up to the management. (If that's any
metric.)
Rolling a key is much less problematic (especially ZSKs) than having
to clean up a "hijacked" delegation. Even a KSK isn't that bad - if
the parent is signed and I never promise my KSK as an SEP.
I once used this argument in a security conference I did a panel on
some years ago. "If I am the operator of a zone and do something to
mess up the private key so bad my regulator wants to fire me, the
regulator does not come for the private key, instead they come for
the database." My concern is first the database over the key, it's
what matters in the event of catastrophic organizational failure.
From that, it's a matter of "fate sharing." What ever I do to
protect my most vital element (database) can be used to protect other
things as well, including the key. I know - what about insiders
mucking with the key? Well, what about the insiders mucking with the
database? Fate sharing.
This isn't a "death-knell" for HSMs in my mind. There are
environments where they are useful. It's just in an environment
which already has a lot of "fortification" an HSM may not be an
improvement, other than to claim "we do it."
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Getting everything you want is easy if you don't want much.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
