Hi Sebastian, On 2011-06-09 15:09 , Sebastian Castro wrote:
For this long list of tables and numbers, you can see the 1280-bit KSK is a good trade-off between key strength and flexibility to operate rollovers in a way that ensures the chain of trust is not broken.
Okay, I now understand how 1280 was chosen (worst case situation still fit into common Ethernet packet without fragmentation, as UDP), and why 1536 wasn't suitable in this worst case situation. Thank you for all the detailed tables. However I'll note that you appear to be solving a problem that (a) few others are solving, and (b) will rapidly become irrelevant. The supposed "can get 1500-byte UDP, but not larger UDP, won't retry properly with TCP" clients will indeed be able to follow the .nz chain of trust in this 1280 situation. But will fail to follow the chain of trust for many other (already deployed) TLDs. So they'll still have to fix their firewall rules/other equipment/whatever to continue to have good connectivity to the modern Internet. (It also seems likely to me that their first response to such broken equipment will be to turn off DNSSEC verification, at which point they won't even be seeing your "optimised to fit" DNSKEY responses, just the smaller ZSK signatures on other RRs they request.) If anything, to echo Jay, this seems like "over engineering" to solve a perceived problem that I'm not really convinced will exist in real life for more than a trivial amount of time. If it turns out that there is a genuine need at the initial deployment to allow more time for people to deal with the packet fragmentation/no-TCP issue, I'd probably live with "1280-bit ZSK in first year, raised to 1536-bit/2048-bit after 12 months" as a policy. But it's not clear to me that even that is needed. Ewen