[DNSOP] Key sizes was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 21 April 2009 16:53 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F51328C2EE for <dnsop@core3.amsl.com>; Tue, 21 Apr 2009 09:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.271
X-Spam-Level:
X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVJqtAXgFiji for <dnsop@core3.amsl.com>; Tue, 21 Apr 2009 09:53:49 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A6AF028C2C9 for <dnsop@ietf.org>; Tue, 21 Apr 2009 09:53:48 -0700 (PDT)
Received: from [10.20.30.163] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LGseZY065926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 09:54:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240807c613a658a056@[10.20.30.163]>
In-Reply-To: <49EDA81E.2000600@ca.afilias.info>
References: <20090306141501.4BA2F3A6B4B@core3.amsl.com> <49EDA81E.2000600@ca.afilias.info>
Date: Tue, 21 Apr 2009 09:54:39 -0700
To: Shane Kerr <shane@ca.afilias.info>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: dnsop@ietf.org
Subject: [DNSOP] Key sizes was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 21 Apr 2009 16:53:50 -0000

At 1:03 PM +0200 4/21/09, Shane Kerr wrote:
>This section does not match up with the tiny bit of crypto research I've
>done. The Wikipedia entry on key lengths references an RSA and a NIST
>publication, both of which suggest 1024 bits not be used after 2010:
>
>http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths
>
>So the "ten years" recommendation goes about 8 years beyond what
>cryptographic experts suggest.

We should be making our recommendations on more than a tiny bit of crypto research. You can read the NIST recommendations directly, for example. They say pretty explicitly that they apply only to US federal use. They also do not suggest that 1024 in 2011 is actually expected to be broken. (Clearly, we should add a pointer to NIST SP 800-57 to this document, even though it seems unlikely that almost anyone will actually read it.)

As I have said repeatedly, the best known attack as of today is against the equivalent of a 700-bit key. NIST's recommendations assume that it is very difficult to change a key as the attacks get better (as they surely will); that assumption is completely false for DNSSEC.

>Perhaps one could suggest 1024-bits is enough for a ZSK that rolled
>relatively frequently. However, looking at the RSA page, we see:
>
>    Arjen Lenstra and Eric Verheul's methodical estimates [LV01] give
>    quite similar results for the security of 1024-bit RSA keys. In one
>    model, they project that in the year 2009, a machine costing about
>    $250 million could factor a 1024-bit RSA key in a day - so a $10
>    million machine would take just under a month.
>
>This seems to imply that one would need to roll a ZSK every few weeks to
> feel safe from cryptographic attacks if using 1024-bit keys.

...assuming that you feel that attacker would spend even a million dollars to break your key. This line of logic completely discounts common sense, however. Which is more valuable to an attacker: the ability to temporarily spoof DNS responses in your zone, or the ability to masquerade as any secure web site they want to?

I'm not advocating that people use 1024 bit keys; that's up to them. If someone wants to use 2048-bit keys that take about four times as much effort to sign and verify, that's great. However, those people should make decisions based on facts about DNSSEC deployment, not extrapolations from estimates that are both speculative and based on key usage that is not applicable to DNSSEC.

--Paul Hoffman, Director
--VPN Consortium