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

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 24 April 2009 16:43 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 7A1553A6966 for <dnsop@core3.amsl.com>; Fri, 24 Apr 2009 09:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 0EdXWRGAfRCe for <dnsop@core3.amsl.com>; Fri, 24 Apr 2009 09:43:25 -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 3E9013A6403 for <dnsop@ietf.org>; Fri, 24 Apr 2009 09:43:25 -0700 (PDT)
Received: from [10.20.30.158] (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 n3OGiIKm080476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2009 09:44:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240813c61798e7e391@[10.20.30.158]>
In-Reply-To: <alpine.LFD.1.10.0904241052270.26808@newtla.xelerance.com>
References: <20090306141501.4BA2F3A6B4B@core3.amsl.com> <49EDA81E.2000600@ca.afilias.info> <p06240807c613a658a056@[10.20.30.163]> <49EE276C.5070706@ca.afilias.info> <p06240814c613f23a6960@[10.20.30.163]> <49EEF042.3070109@ca.afilias.info> <alpine.LFD.1.10.0904221147060.7510@newtla.xelerance.com> <49EFA9C3.6090903@ca.afilias.info> <alpine.LFD.1.10.0904231142590.7788@newtla.xelerance.com> <alpine.LFD.1.10.0904241052270.26808@newtla.xelerance.com>
Date: Fri, 24 Apr 2009 09:42:55 -0700
To: Paul Wouters <paul@xelerance.com>, 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: Re: [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: Fri, 24 Apr 2009 16:43:26 -0000

Thanks, Paul.

At 11:32 AM -0400 4/24/09, Paul Wouters wrote:
>So it seems to me that using 1024 bit RSA keys for ZSK, and 2048 bit
>keys for KSK, assuming RFC 4641 rollover periods, are still many orders
>of magnitude safe for our use within the DNSSEC realm. In fact, it
>seems RFC4641, as written in 2006, is still extremely conservative in
>its estimates two and a half years after its publication date.

That is fine, but so is 1024 bit KSKs. The text in RFC 4641bis makes it clear that KSKs should be rollable in case of an emergency; the effort to do so is greater, but not that much greater, than rolling a ZSK.

The WG should decide which seems better to recommend:

a) KSKs longer than ZSKs because KSKs are thought of as needing to be stronger

b) KSKs the same strength as ZSKs because neither should be weak enough to be attacked

I prefer (b), but (a) keeps coming up in this discussion.

>Note that the same does not apply for DSA. As I understood it, DSA
>requires the use of some randomness for each signature, and the errors
>in the random number generator are cummulative when attempting to crack
>this key. In other words, the more data you sign, the more vulnerable
>you become to the tiniest imperfection in your HWRNG.

That's not the problem. If the per-message random number used in signing is found, the private key is disclosed; there is no requirement for a cumulative error. That has not proven to be a problem for DSA in its current uses, but the random number generator *must* always be a concern.

--Paul Hoffman, Director
--VPN Consortium