On 7/04/2011, at 7:04 AM, Jay Daley wrote:
Hi Joe
On 7/04/2011, at 1:33 AM, Joe Abley wrote:
I've seen top-of-the-line, FIPS140-2 class 4-certified devices new for around USD 10k (and these are not devices you want to buy used, unless you get them reconditioned by a vendor, since you lose a documented chain of custody for the hardware which can make any tiered security policy built above it look like a waste of time).
I realise you're talking about RSA performance here, but there is a good deal of knee-jerk "we need an HSM for security reasons" folklore spreading around the DNS community that I think needs to be damped down.
DNSSEC signatures, as deployed by most people, have relatively short lifetimes (of the order of a week). This implies regular, automated re-signing of individual RRSets, which in turn implies an HSM which is on-line without requiring manual activation, at least for the ZSK. Some signer packages, e.g. OpenDNSSEC, don't support off-line KSK operation so in that case your KSK is on-line too.
Hence, anybody who compromises your signers potentially has full ability to generate signatures using genuine keys. They don't have the ability to run off with the private key materials, but there are plenty of attack vectors where the ability to generate genuine signatures over bogus RRSets is sufficient (and in case of key compromise you can roll your ZSK on a sixpence anyway, and even the process through ICANN, NTIA and VeriSign to roll a DS RRSet in the root zone can be done in 48 hours).
HSMs have their place, but I think it's a mistake to assume that they are necessary in order to maintain adequate security. An appropriate security policy involves a thorough threat analysis, and the results of that analysis might not always hinge on the use of cryptographic modules to store private keys -- in fact, the needless use of HSMs means greater operational complexity, additional hardware support burden, additional compatibility concerns and consequently reduced reliability. Security without reliability doesn't make much sense.
With respect to performance, I think the realistic approach for provisioning purposes is to bear in mind that (a) even TLDs with extensive registrar/registrant DNSSEC uptake like CZ still don't see very high proportions of secure vs. insecure delegations, (b) insecure delegations (NS RRSets and associated glue) aren't signed in the parent zone, so zone size matters less than the number of secure delegations, (c) NSEC3 with opt-out avoids the signature burden of NSEC records, again scaling linearly with DNSSEC uptake by registrants, and (d) you can manage the signature load by imposing jitter on individual signature inception and expiry times to avoid having to do wholesale re-signing of the whole zone except in times of unusual system failure, at which point most bets are off anyway.
Choosing crypto (accelerator) modules based on required performance to do a complete re-sign of the projected zone size in 5 years assuming 100% secure delegations might well serve no better in practice than a vastly lower-spec solution, given the rarity of that scenario.
Sigh. I'm well aware of all of the above and don't need online patronising about it. It is after all what I do for a living.
My question is not really about .nz since we have our signers, but about what kit will be available for registrars, hosting companies and enterprises as they come to rollout DNSSEC. They will have authoritative data, lots of it and will need the performance. They will also have a wide variety of internal security requirements so that some will need plain accelerators and some HSMs. For DNSSEC to be a success, registries need to be supporting their customers in many ways and not just thinking of their own requirements.
This is the second time you've come out with this attitude in this thread, and I for one don't appreciate it. This is a public discussion list, and while you are asking the question, many are reading the answer. I know and understand all of the above as well, but have found it valuable as it challenges some default assumptions people have about how to do this stuff. If this were some kind of business support line, I'd understand your response and lack of desire to be patronised, however that's not the case and on a public list you're going to get answers with more information than you need. If you want to consider that patronising that's fine - I'm sure the rest of us will be thankful to Joe for taking his time to present a whole lot of information and a different potential approach. (I know I do this as well sometimes as I'm sure many others do too, but, hopefully significantly less blatantly) Is anyone aware of DNSSEC software (OpenDNSSEC, what else is there?) being rolled in to Linux distros etc.? What about those control panel things that manage DNS for you (I think cPanel is one)? What is expected when DNS is hosted by a third party - someone like iServe that have a DNS management web interface etc.? Will they hold all the keys for the zone? Will the encryption for these keys require a password from the customer each time? Amazon EC2 does an interesting thing where you create a Windows VM and then ask it for the Admin password - you get shown encrypted data and a box in which to post your private key, and then there is what I believe is a Javascript routine that does the crypto operation to decrypt the password on the client side. Perhaps some kind of client-side signing operation similar to this makes sense? I doubt it'd be terribly practical, but maybe it's worth exploring. "DNSSEC Deployment Scenarios" sounds like an interesting NZNOG talk. (I'm hoping it hasn't already been done while I was having a uh meeting) -- Nathan Ward