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

Joe Abley <jabley@hopcount.ca> Sat, 25 April 2009 03:59 UTC

Return-Path: <jabley@hopcount.ca>
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 6C5FF3A68B0 for <dnsop@core3.amsl.com>; Fri, 24 Apr 2009 20:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 x-T9TCW9sW86 for <dnsop@core3.amsl.com>; Fri, 24 Apr 2009 20:59:34 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id 699A73A6802 for <dnsop@ietf.org>; Fri, 24 Apr 2009 20:59:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=Bm8r47DiYOZm43pkyTinvdFukqyomeNxQSfnKbkqlx1b+sV5G8/zJDDuyF7vgQ2orUH6WaG/0k9Epd/hGfdehYDvjjyT5zCLEJF6FUtxFN8yiCYJHXZ2pNRIxB0pn9A8;
Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from <jabley@hopcount.ca>) id 1LxZ4M-000F9u-Eu; Sat, 25 Apr 2009 04:00:50 +0000
Message-Id: <0EF559B8-03BD-4E83-8656-B2E6DD5E800C@hopcount.ca>
From: Joe Abley <jabley@hopcount.ca>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p0624087fc61828ba995c@[10.20.30.158]>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Sat, 25 Apr 2009 00:00:50 -0400
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> <alpine.LFD.1.10.0904241514300.28588@newtla.xelerance.com> <14F6B497-51D8-4719-B3C2-814A7D20940D@hopcount.ca> <p0624087bc618150afc11@[10.20.30.158]> <90A997B2-4700-479E-9E49-CB84E2FCCBCA@hopcount.ca> <p0624087ec61821fc04bf@[10.20.30.158]> <F37ECB0D-D4B4-4AB5-A45B-134235961EBC@hopcount.ca> <p0624087fc61828ba995c@[10.20.30.158]>
X-Mailer: Apple Mail (2.930.3)
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: Sat, 25 Apr 2009 03:59:35 -0000

On 24 Apr 2009, at 22:45, Paul Hoffman wrote:

> At 10:25 PM -0400 4/24/09, Joe Abley wrote:
>
>> My point is that given the choice between "doing what is currently  
>> considered safe" and "exceeding what is currently considered safe  
>> by a factor of four with no additional cost to you" I think many  
>> otherwise uninformed zone administrators are conditioned to choose  
>> the latter.
>
> ...which a good reason why we give actual numbers in this draft.
>
> I don't see where you are going with this.

Yeah, sorry for being vague.

> Do you want us to give hard numbers and not justify them so admins  
> won't pick anything else?

The advice in the document seems fine. I wonder whether it is complete.

If there's an expectation that people will choose bigger keys because  
they can, and that there are operational reasons why this would be  
bad, it seems sensible to explain those reasons as additional  
incentive for people not to do it. I don't think the current text  
really identifies those reasons very clearly.

But really I was more concerned that it wasn't obvious what those  
operational reasons might be.


Joe