Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

Joe Abley <> Thu, 27 March 2014 22:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C72F71A014C for <>; Thu, 27 Mar 2014 15:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XWkQhHICu7et for <>; Thu, 27 Mar 2014 15:47:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22d]) by (Postfix) with ESMTP id 922FB1A0245 for <>; Thu, 27 Mar 2014 15:47:52 -0700 (PDT)
Received: by with SMTP id t19so129567igi.0 for <>; Thu, 27 Mar 2014 15:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UEsdkpuXes5jWbOgB/yIB56IhfLcc+uXBMMU1Cu5FSw=; b=bdZ1du9grPcJtMFAERGIAcqhK99kxRwriez5GNFPbsS4BzXgsCcgpEmB36a9TwA2j1 fnFYASKia0IFJcHK5qMz6PBbBg2feLVn3yQIEKWynT9ECToJ/6v1v9x8TqAE5nwu6MPT karzq65Vb+OdVrJwY4n6+48A6XrPLesvBXYDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=UEsdkpuXes5jWbOgB/yIB56IhfLcc+uXBMMU1Cu5FSw=; b=czh9sIi5jJpyttByabE5qMQjWPT1vTm2dvLRg9PpqvSHnh1BCQITy+Wqagb8R5jnEj cDqT+x+F33AVg5TsEZqcg5rRX6qvvXBXaFZ8tcn6lVLrEbt8gGOVDt/zJtSsnWT0qSNM /iu3YXJ6n6GbEMTWBWNzRlnLIC7rUeSOjMx0hqzrvBdNVGTOHYzU/dEMlHOnQ6YABrrX LQXd4/o2CulzJbMClDmi2TkWGnRAnE2KYn+tv/omVuLdjI8460d+JLGi0KR2MDIAQ/bt h0l4lOnAIjGSP4D3yH2JO9YT9ZVMETVlvNdPkkvfE/+W2PNZZRn5gfYO1UqcdJmthocj 9llg==
X-Gm-Message-State: ALoCoQk2f4EXO/jFjJuYF0ABvsy8Wb+KRH6kviEsuD0wKAVNHpK9nHxeFVpmu4lWjZSGggm3Exfj
X-Received: by with SMTP id hh6mr4775152icc.68.1395960469712; Thu, 27 Mar 2014 15:47:49 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id b8sm636272igx.3.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 15:47:48 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_316769F6-8391-4CA5-848B-D0BD086643BA"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Joe Abley <>
In-Reply-To: <>
Date: Thu, 27 Mar 2014 17:47:46 -0500
Message-Id: <>
References: <> <> <>
To: Nicholas Weaver <>
X-Mailer: Apple Mail (2.1874)
Cc: dnsop WG <>
Subject: Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Mar 2014 22:47:55 -0000

On 27 Mar 2014, at 10:05, Nicholas Weaver <> wrote:

> On Mar 27, 2014, at 7:22 AM, Joe Abley <> wrote:
>> On 27 Mar 2014, at 22:56, Nicholas Weaver <> 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:
>> (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.