Paul, 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! > 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. 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. (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.) While you may not advocate that people use 1024 bit keys, the draft spends 5 paragraphs advocating 1024 bit keys. I obviously think this is a misguided recommendation. At the very least we should tone it down a bit. -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
