On 9 nov 2010, at 01.23, Paul Wouters wrote: > Which HSM and which openssl version on what type of computer? A decent > quadcore outperforms > an HSM in my experience.
The Sun SCA6000 gives you 13 000 sig/s for a 1024-bit rsa. And you can cluster e.g. three of them to get 40 000 sig/s The test server is perhaps three years old. Sun Microsystems Sun Fire X4100 M2 Processors: 2 x Dual-Core AMD Opteron 2793 MHz openssl speed rsa1024 -multi 4 8333.3 sig/s (4 threads was the fastest combination) Conclusion: The speed of an HSM is comparable with doing it in software. >> 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) Yes, the affect the rollover time, but this does not limit your choice of the signature validity period for the KSK. If you read the statement in the draft, then it sounds like the ZSK can have a shorter signature validity period because it does not interact with the parent. >> 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. Yes, I used the numbers from "Table 2: Digital Signatures Security Strength Transitions" Just wanted to point out that there are people who do not think 1024-bit keys are safe for at least the next ten years. >> 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...... As the others say, the SEP bit does not prevent a key from being used for signing/validating other zone data than the key set. The draft now just follows the regular definition of a KSK, but it does not limit the actions of the attacker to only sign the key set. (and if there was a limit, then the attacker off course includes its own new ZSK in the key set). So when describing what an attacker could do, we should describe what it could do rather then what a normal signer should do. >> 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? As Roy said, size of the DNSKEY RRset. > If the "DS update" mechanism would be compromised (eg webgui at registry) then > this might allow an attacker to spoof a zone? If they can comprise the DS update mechanism, then they probably can do stuff to the NS. > 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. Are they bogus if there is no DNSKEY? The reason that I want this is for may standby key mechanism below, where you just publish the DS, but not the DNSKEY of the KSK. >> 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) I agree with Roy's answer. >> 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. It might also be that you signing system breaks down, or that there is a bug in your HSM:s which prevent you getting access to the keys. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
