At 12:24 PM +0200 4/22/09, Shane Kerr wrote: >You seem to think that because there are higher-value targets nobody >would ever bother to attack a 1024-bit DNSSEC key.
Correct. Why would an attacker waste resources attacking a target with lower value than other targets? This is Security 101. >My point is that once >the investment has been made to attack SSL certificates, the tools can >just as easily be used for DNSSEC. And I agreed with that assessment. >So rather than feel safe because someone else is a nicer target, we >should worry because cracking technology reduces the safety of all keys. We disagree here. People with targets that are not near the top of the target list can feel safer *and* we should worry because cracking technology reduces the safety of all keys. Right now, no one has come even close to attacking a 1024-bit key in public. At some point in the future, that will change, either by a researcher doing it, or by a miscreant doing it and being caught. That will be a data point for everyone (DNSSEC zone holders, CAs, organizations with PKIX certificates, and relying parties for all the above) to decide what they should do next about key sizes. Some of those parties will decide before the first public attack; for example, NIST wants to be ahead of the curve and has set a date of Jan 1 2011 for US Federal users. Others may do the same, or might wait for better data. >Basically, if it's 3x slower to verify but this means using 30 seconds >of CPU time for all validations in the lifetime of the zone instead of >10 seconds, then we might as well longer keys. These kinds of calculations are exactly what I hope zones use when they decide what key length to choose. >So, to recap: > >- People who get a lot of traffic will probably want longer keys because > they are a valuable target. >- People who do not get a lot of traffic might as well use longer keys > because the total cost to them and their users will be minimal. And these are not. I fully disagree that FadSiteOfTheYear.com is a more valuable target than SmallLocalBank.com. >My replacement wording would be simply: "unless you have a reason to >worry about bandwidth or CPU time of validating resolvers, use 2048 bit >keys, because this will be safe for the foreseeable future". That's one option, similar the current 4641. The option that some people think is better is to explain to them what the bandwidth and CPU tradeoffs are, and to explain what is foreseeable. > >> 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. > >I'm not sure how this will lead to worse security, but I agree using >longer keys would result in extra CPU cycles being used. If you don't explain what the options are, operators will pick inappropriate options. Some of those choices will inevitably be for worse security. >I don't think this is a waste, really. I think if we recommend 1024 as >the text does, then we'll have to revisit it in 3 or 4 years. If you're predicting that there will be public breaking of 1024-bit keys in "3 or 4 years", you may want to justify that prediction, given that we haven't even seen a break that is literally hundreds of times easier. >I would >prefer to pick a key length that will last a decade or two (pending >quantum computing or suchlike), or at the very least not recommend 1024 >so strongly. Great: pick such a key! The point of the proposed text is to let people pick what is appropriate for them, not what any one of us thinks. If you have evidence that 1024-bit keys are breakable within a few years, that would be valuable to include. In fact, there are literally hundreds of CAs who would want to hear it as well, and we should publish a parallel document covering TLS, IPsec, S/MIME, and so on. At 12:55 PM +0100 4/22/09, Chris Thompson wrote: >There are *two* cost figures involved in the hypothetical cracking. >There is the setup cost of the equipment, to which the $10million refers, and >the incremental cost of cracking a particular key. Even >if the latter is "how long do I have to dedicate my $10million >equipment to cracking this particular key". >The right model is probably "how much do we have to charge Black Hat, Inc. >per key we crack for them, to make a decent profit?". Exactly right. (Well, the third question is whether or not the guesses of $10 million still stand up.) --Paul Hoffman, Director --VPN Consortium _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
