On Apr 2, 2014, at 11:19 AM, 🔒 Roy Arends <r...@dnss.ec> wrote: > > Just a thought that occured to me. Crypto-maffia folk are looking for a > minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk > are looking for a maximum (i.e. at most soo many bits otherwise > fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum > might actually be larger than the DNS-maffia’s maximum.
The problem from the dns-op maximalist viewpoint is there is basically two magic numbers: 512B and ~1400B. As someone who's measured this, the 512B is not a problem, but the 1400B "here be fragments" is. Yet at the same time, the current 1024B ZSK/2048B KSK configuration on TLDs does blow through it: I reported in the previous thread how org's DNSKEY record already blew past that limit. And even in that case, resolvers can handle "fragments don't work", albeit with a latency penalty. So its not a "DNSSEC fails" point but simply "performance degraded". So the real question is "do the common answers fragment", the ones with short TTLs that are accessed a lot, have a fragment problem. With 2048b keys, they don't: the one that gets you is NSEC3, and that only blows up in your face on 4096b keys. (But boy does it, those 3 RRSIGs get big when you're using 4096b keys). And please don't discount the psychology of the issue. If DNSSEC wants to be taken seriously, it needs to show it. Using short keys for root and the major TLDs, under the assumptions that it can't be cracked quickly (IMO, we have to assume 1024b can be.) and that old keys don't matter [1], is something that really does draw criticism. [1] IMO they do until validators record and use a 'root key ratchet': never accept a key who's expiration is older than the inception date of the RRSIG on the youngest root ZSK seen, or have some other defense to roll-back-the-clock attacks. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
