On 24 Apr 2009, at 21:17, Paul Hoffman wrote:
At 7:53 PM -0400 4/24/09, Joe Abley wrote:
It seems fruitless to debate whether 1024 bits is sufficient if
there's no real cost to just choosing (say) 4096 bits and avoiding
the discussion.
Please read the text: larger keys incur a real cost to people
validating.
The text contains the following sentence: "In a standard CPU, it takes
about four times as long to sign or verify with a 2048-bit key as it
does with a 1024-bit key." I couldn't find any other discussion of the
cost to validators of large key sizes.
If there is a practical limit to key size due to concerns about
peoples' validators running out of steam, then I think it needs to be
stated clearly. Otherwise as a zone administrator my instinct will be
to use keys that are as large as possible, since the costs incurred by
doing so are going to be borne by other people and all I see is
benefit (in the form of increased comfort level and a better story for
upper management, even if there is no practical improvement in
security).
On the flip side, how can the "real cost" for validator-operators that
you assert be quantified?
I have a hand in running a couple of non-validating resolvers for a
local ISP. 35,000 customers are served by two machines running BIND
9.5.x on FreeBSD 7.1, and the CPUs are 96% idle at peak load. That's a
fair amount of headroom, even ignoring the fact that the ISP in
question is in the process of replacing each machine with an ECMP/OSPF
cluster of two machines in order to simplify ad-hoc maintenance.
I'm not arguing about the assertion that there is a limit to what
validators can tolerate. However, it seems reasonable to ask if it's
the kind of limit that we need to worry about, and not, the kind of
limit that is always going to fit in that headroom as validator
hardware gets upgraded on a typical cycle and DNSSEC deployment
proceeds over time.
Joe
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
