On 06/09/2011 03:37 PM, Ewen McNeill wrote:
Hi Sebastian,
Hi Ewen,
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.)
I agree with point a), just a few are trying to solve the problem. This could be explained by who will be affected: a DNS operator is not likely to see the retries/dropped fragments from clients behind poorly-implemented firewalls, thus going unnoticed. In order to have a clear picture, more monitoring like the one done by Netalyzr is needed (http://conferences.npl.co.uk/satin/papers/satin2011-Weaver.pdf) About point b), a validating caching resolver is likely to stop DNSSEC validation if it causes problems (the path of least resistance). We don't want that. As you said, those clients will be able to continue resolving .nz domain names but they might fail with other TLDs, so we are not making the problem worst.
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.
Cheers,
Ewen _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535