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

Paul Wouters <paul@xelerance.com> Fri, 24 April 2009 20:02 UTC

Return-Path: <paul@xelerance.com>
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 BE8D828C5BA for <dnsop@core3.amsl.com>; Fri, 24 Apr 2009 13:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Level:
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 dtV63i8XSJV0 for <dnsop@core3.amsl.com>; Fri, 24 Apr 2009 13:02:19 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1EB0628C745 for <dnsop@ietf.org>; Fri, 24 Apr 2009 13:02:08 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 2AE695705F; Fri, 24 Apr 2009 16:03:25 -0400 (EDT)
Date: Fri, 24 Apr 2009 16:03:24 -0400
From: Paul Wouters <paul@xelerance.com>
To: Evan Hunt <Evan_Hunt@isc.org>
In-Reply-To: <20090424174722.GA30229@isc.org>
Message-ID: <alpine.LFD.1.10.0904241514300.28588@newtla.xelerance.com>
References: <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> <p06240813c61798e7e391@[10.20.30.158]> <20090424174722.GA30229@isc.org>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: dnsop@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, Shane Kerr <shane@ca.afilias.info>
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 20:02:20 -0000

On Fri, 24 Apr 2009, Evan Hunt wrote:

>> 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.
>
> It's a little imprecise, but I'm inclined to think of key lifetime as an
> aspect of key strength.  A 1024-bit key that rolls over every week may be
> "stronger", in a sense, than a 2048-bit key that stays around for twenty
> years--the second one could be broken within its lifetime, the first one
> probably not.

But the essential part is that once you see, say after 10 years, that the KSK
2048 bit key comes into the "feasable but impractial" scale of things due
to advacements in math or technology, that you can decided to roll it over
fairly quickly.

> IMHO it's reasonable to make recommendations with that tradeoff in mind; a
> ZSK may be as long as a KSK, or it may be shorter if it's rolled over more
> frequently.  (I think 4641bis already says something along those lines.)

What I was told by my "lunching cryptographer" was that 1024bits were more
then enough even for multi year KSK's, assuming sining only, no encryption.

>From a cryptography strength point of view, more is always better,
but now you need to consider work done by you and resolvers, and space
constrictions with the DNS packet size.

I don't see a cryptographic reason for Paul Hoffman's "I'd like the keys to
be of equal size". Unless you'd argue that the KSK could easilly also be
1024bit, and that the additional 11 months of validity of the KSK is
negligable compared to the time now upto 3 years from now, to break a 1024
bit RSA key.

Paul