On 27 Mar 2014, at 10:05, Nicholas Weaver <nwea...@icsi.berkeley.edu> wrote:
> On Mar 27, 2014, at 7:22 AM, Joe Abley <jab...@hopcount.ca> wrote: > >> On 27 Mar 2014, at 22:56, Nicholas Weaver <nwea...@icsi.berkeley.edu> wrote: >> >>> Bits are not precious: Until a DNS reply hits the fragmentation limit of >>> ~1500B, size-matters-not (tm, Yoda Inc). >>> >>> So why are both root and com and org and, well, just about everyone else >>> using 1024b keys for the actual signing? >> >> Those requirements (for the root zone keys) came from NTIA via NIST: >> >> http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.pdf >> (9)(a)(i) >> >> (well, NIST specified a minimum key size, but the implication at the time >> was that that was a safe minimum). > > Obligatory Snarky Note: these being the same people who, after 2007, said > that, although you can create your own constants, you MUST still use the > specified magic constants for Dual_EC_DRBG if you wanted certification, even > though it was shown that whoever generated the magic constants could have > placed a backdoor in them... I wasn't defending the key size; I was just explaining how it was chosen by the team who signed the root zone. (We did a global roadshow to technical audiences laying out details such as key sizes, incidentally, and never got a single piece of feedback that 1024 was too small. So if there's blame for a poor decision to be apportioned, let's spread it round evenly and grimace shamefully, together.) There was a plan underway to roll the KSK. I was at ICANN briefly when that started (I spoke publicly, albeit briefly about it in the dnsop meeting in Berlin). I'm no longer at ICANN and hence no longer have anything authoritative to say, but it seems plausible that the events leading up to NTIA's announcement the other week caused some delays or rescheduling of the KSK roll project. A KSK roll would be a good opportunity to change the key size. There's a public consultation going on at ICANN about the future stewardship of the IANA Functions. I am aware that various technical/security groups are planning to submit comments. Drawing attention to potential weakness in the root zone ZSK as an operational input to that consultation does not seem like a horrible idea. Joe
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
