On Mon, 8 Nov 2010, Rickard Bellgrim wrote:
3.1 Operational Motivations (5th paragraph) Is it true that you get “operational flexibility and higher computational performance” by using a file based ZSK and smartcard KSK (offline in a safe) than a single key stored on an HSM? The HSM can give you the option to have the keys online, thus no need to take out the smartcard from the safe. And the HSM can be designed to give you speed. I know that my HSM is faster than OpenSSL on my machine.
Which HSM and which openssl version on what type of computer? A decent quadcore outperforms an HSM in my experience.
3.2 Practical Consequences (2nd paragraph) The statement is that you can have signature validity periods on the order of days for ZSK signatures, because there is no interaction with the parent during a key rollover. Well this is not true. There is nothing that prevents you from having short validity periods for KSK signatures. ZSK and KSK is thus equal in that aspect.
It depends on how long the parent's DS/NS records are valid for (TTL) and how fast they can update the DS record. It's not fully in your control, so there is some possible delay (and you NEED a monitor to avoid a bad rollover)
3.4.2 Key Sizes (1st paragraph) “can safely use 1024-bit keys for at least the next ten years”. NIST SP 800-131 says that 1024 – 2048 bit is acceptable to use in 2010. It is deprecated between 2011 and 2013. From 2011 you should use keys larger than 2048 bits. http://csrc.nist.gov/groups/ST/toolkit/documents/draftSP800-131_June_11_2010.pdf
key size depends on key usage. The NIST SP (if I remember correctly) lists 1 validity time for both volatile signatures and long term encryption. In fact, talking to cryptanalists, the 10 years could even be extended, but it was used as a very conservative number.
4.2.1 KSK Compromise (2nd paragraph) A compromised KSK used by an attacker can also sign data in the zone other than the key set. An attacker does not need to follow the definitions of KSK vs ZSK.
I wonder how different implementations handle this case......
4.3.1 Initial Key Exchange I also think that it should be possible to send in a DS RR for which there is no DNSKEY in the child zone. I know that there are registries that disallow this and others allow this. The reason is to not limit any (future) rollover mechanism. What we could say is that there should be at least one of the DS RRs pointing to a DNSKEY.
4.3.3 Security Lameness (2nd paragraph) No, the parent should allow DS RR pointing to non-published DNSKEY. We should not limit any (future) rollover mechanisms. There should of course be at least one DS pointing to one DNSKEY.
If you already know the DNSKEY (because you have the DS record), what would be the use of not already publishing that DNSKEY? If the "DS update" mechanism would be compromised (eg webgui at registry) then this might allow an attacker to spoof a zone? Verification that the DNSKEY is actually there would offer additional protection. I think it is better for resolvers not to have to try too many bogus trust paths by adding "bogus" DS records.
5.3.3 NSEC3 Salt (3rd paragraph) You recommend doing re-salting at the same time as ZSK rollover. But it is not required to drop all signatures at once during a ZSK rollover. This can be a smooth transition determined by the refresh period.
I thought you would always have the new ZSK sign all the zone data, and just keep the old ZSK for cached sigs? So in that case, yes you always drop all signatures during a ZSK rollover (on the signer, TTL's and SigMax will cause a spread out expiry of the old sigs on caching validating resolvers)
Finally: You are missing text about standby keys. Used to speed up the rollover in case of an emergency. But also as part of your disaster recovery, when you have lost access to your keys and the backups cannot be restored. This is how you do it: 1. Generate standby KSK and ZSK. Store them safely. 2. Prepublish standby ZSK in zone. 3. Prepublish DS of standby KSK in parent zone. 4. You have a disaster. 5. Create a new datacenter and import the standby keys. 6. Postpublish old ZSK in zone (fetch it from a secondary somewhere). 7. Sign and publish zone. 8. After "some" TTL remove old ZSK and old DS 9. Continue with normal operation.
I find this very odd. You publish "bad data" just because you might have a bad backup? It seems like outsourcing your responsibilities, at the cost of everyone's resolvers needing to handle a bogus DS record. And why would the disaster not destroy the standby keys? And if you have a safe method for the standby keys, why did you not use it for the current keys as well, thereby preventing the (DNS) disaster. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
