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

Nicholas Weaver <> Tue, 01 April 2014 13:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B0841A06FF for <>; Tue, 1 Apr 2014 06:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5-i6dH-sbzRF for <>; Tue, 1 Apr 2014 06:05:26 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 881F21A0708 for <>; Tue, 1 Apr 2014 06:05:26 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5D23A2C4023; Tue, 1 Apr 2014 06:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([]) by localhost (maihub.ICSI.Berkeley.EDU []) (amavisd-new, port 10024) with LMTP id DWkuaiZAWtNo; Tue, 1 Apr 2014 06:05:20 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 529F62C400B; Tue, 1 Apr 2014 06:05:20 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_7AB08333-28B2-49DA-BD79-FF2ED3244C6F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Nicholas Weaver <>
In-Reply-To: <>
Date: Tue, 1 Apr 2014 06:05:20 -0700
Message-Id: <>
References: <> <> <> <>
To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= <>
X-Mailer: Apple Mail (2.1874)
Cc:, Nicholas Weaver <>, =?iso-8859-1?Q?Matth=E4us_Wander?= <>, Bill Woodcock <>
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: Tue, 01 Apr 2014 13:05:28 -0000

On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson <> wrote:
> Doing these big jumps is the wrong thing to do, increasing the key size increases three things:
> 	time to generate signatures  
> 	bits on the wire
> 	verification time. 
> I care more about verification time than bits on the wire (as I think that is a red herring).
> Signing time increase is a self inflicted wound so that is immaterial. 
>                  sign    verify    sign/s verify/s
> rsa 1024 bits 0.000256s 0.000016s   3902.8  62233.2
> rsa 2048 bits 0.001722s 0.000053s    580.7  18852.8
> rsa 4096 bits 0.012506s 0.000199s     80.0   5016.8
> Thus doubling the key size decreases the verification performance by roughly by about 70%. 
> KSK's verification times affect the time to traverse the DNS tree, thus 
> If 1024 is too short 1280 is fine for now
> If 2048 is too short 2400 bit key is much harder to break thus it should be fine. 
> just a plea for key use policy sanity not picking on Bill in any way.

NO!  FUCK THAT SHIT.  Seriously.

There is far far far too much worrying about "performance" of crypto, in cases like this where the performance just doesn't matter!

Yes, you can only do 18K verifies per CPU per second for 2048b keys.  Cry me a river.  Bite the bullet, go to 2048 bits NOW, especially since the servers do NOT have resistance to roll-back-the-clock attacks.

In a major cluster validating recursive resolver, like what Comcast runs with Nominum or Google uses with Public DNS, the question is not how many verifies it can do per second per CPU core, but how many verifies it needs to do per second per CPU core.

And at the same time, this is a problem we already know how to parallelize, and which is obscenely parallel, and which also caches...

Lets assume a typical day of 1 billion external lookups for a major ISP centralized resolver, and that all are verified.  Thats less 1 CPU core-day to validate every DNSSEC lookup that day at 2048b keys.  

And yeah, DNS is peaky, but that's also why this task is being run on a cluster already, and each cluster node has a lot of CPUs.

Nicholas Weaver                  it is a tale, told by an idiot,                full of sound and fury,
510-666-2903                                 .signifying nothing