At 10:07 PM +0200 4/21/09, Shane Kerr wrote: >Paul Hoffman wrote: >> >> ...assuming that you feel that attacker would spend even a million dollars >> to break your key. This line of logic completely discounts common sense, >> however. Which is more valuable to an attacker: the ability to temporarily >> spoof DNS responses in your zone, or the ability to masquerade as any secure >> web site they want to? > >The same RSA-cracker that our evil-doers dropped $10 million on to hack >web SSL will work nicely for RSA DNSSEC, thanks!
You're welcome. :-) Of course it will. It will also work on all other 1024-bit keys. If you believe that your DNSSEC key is worth more to an attacker than those other keys, then you should use a larger key. Nothing special here. > > I'm not advocating that people use 1024 bit keys; that's up to them. If > > someone wants to use 2048-bit keys that take about four times as much > > effort to sign and verify, that's great. However, those people should make > > decisions based on facts about DNSSEC deployment, not extrapolations from > > estimates that are both speculative and based on key usage that is not > > applicable to DNSSEC. > >I look at it like this: > >High-volume and/or high-profile sites are the very ones that will most >likely be attacked, and the ones that should really consider a longer >key length for security. Of course. They should also really consider whether or not they will ever get attacked. If not (because attackers will be more interested in other keys), then that is an input to their decision-making. 'Twas ever thus. > Low-volume and/or low-profile sites don't >really need to care about the computation time expended, because in the >end we're not talking about a lot of bandwidth or cycles in total. I don't understand this. It is not the end users who will be spending the cycles doing signature validation, it is the validating resolvers. >(The >computational losers in DNSSEC are, as always, the validating resolvers. >I don't know of any benchmarks showing the cost of relative key sizes >for resolvers though, so it's all a bit hand-wavy, but it could be a >real problem.) 'openssl speed rsa1024 rsa2048' is your friend here. On my laptop, signing takes six times longer, but verifying only takes three times longer. Different platforms will give different results. >While you may not advocate that people use 1024 bit keys, the draft >spends 5 paragraphs advocating 1024 bit keys. No, it doesn't. It spends five paragraphs saying "you're probably fine with 1024 bit keys, but consider the consequences". If you have replacement wording, it would be great to see it. >I obviously think this is >a misguided recommendation. At the very least we should tone it down a bit. I fully disagree with "tone it down". This is an operational document. Telling operators what they should consider when making policy is *much* better than giving them a summarized number that may not apply to DNSSEC at all. Others may disagree and want a single summarized number; however, in that case, 1024 would apply to more readers than 2048 would. Not letting the reader decide for themselves will lead to either worse security or needlessly wasted CPU cycles. --Paul Hoffman, Director --VPN Consortium _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
