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

Nicholas Weaver <nweaver@icsi.berkeley.edu> Thu, 27 March 2014 13:56 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 364671A032A for <dnsop@ietfa.amsl.com>; Thu, 27 Mar 2014 06:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id P3uCIsAydFmZ for <dnsop@ietfa.amsl.com>; Thu, 27 Mar 2014 06:56:08 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU []) by ietfa.amsl.com (Postfix) with ESMTP id 5803D1A010F for <dnsop@ietf.org>; Thu, 27 Mar 2014 06:56:08 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DE2D82C4039 for <dnsop@ietf.org>; Thu, 27 Mar 2014 06:56:06 -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 Kqw0Zzj-tvw0; Thu, 27 Mar 2014 06:56:06 -0700 (PDT)
Received: from [] (c-76-103-162-14.hsd1.ca.comcast.net []) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 440F42C4022; Thu, 27 Mar 2014 06:56:06 -0700 (PDT)
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Content-Type: multipart/signed; boundary="Apple-Mail=_EA0FA789-1469-49F3-9D0B-43276121AE45"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Thu, 27 Mar 2014 06:56:05 -0700
Message-Id: <0EA28BE8-E872-46BA-85FD-7333A1E13172@icsi.berkeley.edu>
To: dnsop WG <dnsop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/3hzGyV9LGnUpw0ncFudWdQ2sZvc
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: [DNSOP] Whiskey Tango Foxtrot on key lengths...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 13:56:10 -0000

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?

The biggest blobs of typical DNSSEC data are NSEC3 responses, and upping the key size to 2048b everywhere will not cause widespread fragmentation issues (4096b will... but only on those NSEC3 blobbies which require three RRSIGs, you can get non-NSEC3 responses to fit under that limit in most cases as those require only one or perhaps two RRSIGs)

1024B is unquestionably too weak, 768-bit RSA has been factored in 2010 as a low resource academic project:

and 1024B is estimated at only "a thousand times harder".

RSA 768 took just 1,500 CPU-years on the fully parallelizeable sieving step, and 4 days of total time (but only 12 hours of successful computation) on a couple of ~35 node clusters.

And, frankly speaking, a 3500 node cluster for a day is $75K thanks to EC2.

Do you really want someone like me to try to get an EC2 academic grant for the cluster and a big slashdot/boingboing crowd for the sieving to factor the root ZSK?

So why the hell do the real operators of DNSSEC that matters, notably com and ., use 1024b RSA keys?

And don't give me that key-roll BS: Give me an out of date key for . and a MitM position, and I can basically create a false world for many DNSSEC-validating devices by also providing bogus time data with a MitM on NTP...

IMO, it is time for DNSSEC software to refuse to generate new RSA keys less than 2048b in length, and for the TLD and root operators to ditch short keys into the trash heap of history.  Well, the time was actually a decade ago, but hey...

If people actually want DNSSEC to be taken seriously as a PKI-type resource (a'la DANE), the DNS community needs to actually, well, use secure crypto.  1024b RSA is not secure.  Go Big or Go Home.

Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc