On 2011-06-14, at 21:48, Nigel Roberts wrote:
http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04
It seems that this would go a long way to reducing response size while maintaining a politically and technically acceptable level of security. Hopefully the draft comes back to life or is replaced by something better.
I believe there is still a good amount of enthusiasm for using new ECC algorithms in DNSSEC. I'm no cryptographer, but I believe GOST is an example of such an algorithm (see RFC 5933). GOST is supported in recent releases of BIND9, NSD and Unbound. If you want to learn more, go and browse the dnsext mailing list archives (or ask on that list). However, the point that I wanted to make was that we have now had numerous examples of enlarged response size due to the deployment of DNSSEC. We've seen (accidental) massive increase in the use of TCP transport in ORG due to a TTL mishap on ORG's SOA resource record, and we've also tested the impact of large priming query responses in the root zone. I am not aware of any harm to any client that resulted from either of these (that is, nothing was noted publicly or, in the case of the root zone, publicly or privately). So while I think it's always prudent to be conservative with the client population, especially in the case of the DNS where the client population is impossible to characterise accurately in detail, I don't think response size ought necessarily to be the primary consideration when choosing signing parameters (including key size). Joe