Re: [DNSOP] Key sizes was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt

[Shane Kerr <[e-mail]>]

Paul Hoffman wrote:
> 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.

You seem to think that because there are higher-value targets nobody
would ever bother to attack a 1024-bit DNSSEC key. My point is that once
the investment has been made to attack SSL certificates, the tools can
just as easily be used for DNSSEC.

So rather than feel safe because someone else is a nicer target, we
should worry because cracking technology reduces the safety of all keys.

>>> 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.

When I wrote "in the end", I didn't mean for the end users, I meant "in
the end":

http://www.thefreedictionary.com/in+the+end

As the example says, "All will turn out well in the end." :)

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.

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.

>> (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.

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".

>> 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.

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. 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.

--
Shane