On Tue, 21 Apr 2009, Edward Lewis wrote:
I mentioned that the "value in protecting the private key is a function of the cost of rolling to a new key."
Plus your legal bill explaining in court over and over again why you were not legally responsible for costs of the breach. The million dollar question becomes "If you had used an HSM, would this attack have been possible?". There are some attacks where you will have to answer "no".
If the key is a SEP, it's the cost of rolling it through the trust anchor repositories, if the key is a lowly ZSK, then it's more or less just the liability for goofing up. It's not like someone reading the key is going to unlock encrypted state secrets and such.
No, they just connect to the bogus largebank.com and steal more then your gross turnover....
I guess the equation is - the cost of an HSM vs. the value of saving one's operations from key "exposure." (Not the same as a forged response.)
Key exposure is very similar to unsigned zone data exposure, since if you don't detect unsigned data changes, you will just sign them with your key. As such, an HSM does not bring you much value per se.
Sorry if it sounds like I'm just talking in circles. But I can't see the very vulnerability that an HSM addresses as being likely enough to be worth addressing given all the other vulnerabilities.
The one it mostly protects against is someone stealing a copy of the key, and signing items not local to you but to their targets. You will not experience anything, and it might be hard for you to detect you lost your key unless you detect the intrusion. But rogue signed data never comes back to you. When using an HSM, attackers have to maintain access to the compromised data and any rogue signed data lives within your own infrastructure and could be more easilly detected (when complains come in about the rogue signed data) I am tempted to lean towards using a KSK in an HSM, and using the ZSK without an HSM, due to the speed limitations of the HSM's signing bulk data, and the relative ease of replacing the ZSK, together with current strong security on the unsigned data and servers currently in use by TLDs. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
