[DNSOP] HSMs was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt

[Edward Lewis <[e-mail]>]

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 [phone]

Getting everything you want is easy if you don't want much.