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. Jay
Joe
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840