On Thu, Jan 22, 2015 at 10:12 AM, Paul Wouters <[email protected]> wrote: > > On Wed, 21 Jan 2015, David Conrad wrote: > >> Thanks very much for this note. The issue of the ZSK length is something >> that has popped up on various radars on various occasions and given the >> recent publicity over at imperialviolet and sockpuppet on 1024 bit RSA, it'd >> be good to explore this in more detail to see what level of nightmare we'd >> be inflicting upon ourselves (if any). > > > I think it was a bigger problem when the root was signed at first. > >>> In other words, which ever clients cannot handle a root ZSK of 2048 >>> already has a severe problem with DNS. I don't think we would be adding >>> much of a problem by just switching to 2048 today. >> >> >> While I tend to agree, this assumes the clients would notice, which >> obviously depends on the names being looked up. Do you have any idea of >> (say) the popularity of the names behind large RRsets (e.g., their Alexa >> ranking or something similar)? > > > No, I don't. Someone at a big caching server would be in a much better > position to get that data. > >>> Of course, once you believe we can do a ZSK of 2048, there is no urgency >>> to move to ECDSA and we can wait on the CRFG to come up with a non-DSA >>> ECC algorithm for us. >> >> >> Yep. I'd really like to go to ECDSA, but it doesn't look like there is >> enough support out there for it (at least for root purposes). > > > Some people would like to skip ECDSA for a more modern ECC variant. > >> I guess a larger question is "do we care?". I'll be honest and say I'm >> increasingly concerned that broken middleware-driven ossification is getting >> in the way of fixing serious problems. > > > And those middle boxes already have a fallback - don't query with DO.
There have been repeated questions about how big DNSSEC keys should be. We are also interested in understanding at what point IPv4 fragmentation becomes common in UDP responses as key size increases, since IPv4 fragmentation brings performance problems such as packet re-transmission due to loss fragments. We analyze two DNS traces captured at a root server and a TLD server, by replacing the current 1024-bit RSA signature with longer ones. We find that: 1. A root trace suggests there is minimum (almost no) risk to go to 2048-bit ZSK and 2048-bit KSK for root server. 2. A TLD trace shows 5.5% DNSSEC enabled responses getting IPv4 fragmented with 2048-bit ZSK and more with longer keys. We suggest TLD and other authoritative server operators analyze their server's response traffic and inform their customers of possible problems before moving to use longer keys. For details of our methodology and graphs, please see http://isi.edu/ant/tdns/keysize.html -Liang Zhu _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
