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

Shane Kerr <shane@ca.afilias.info> Tue, 21 April 2009 11:02 UTC

Return-Path: <shane@ca.afilias.info>
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 846FD28C10A for <dnsop@core3.amsl.com>; Tue, 21 Apr 2009 04:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.12
X-Spam-Level:
X-Spam-Status: No, score=-4.12 tagged_above=-999 required=5 tests=[AWL=0.853, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4]
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 iAmqoyVihFXs for <dnsop@core3.amsl.com>; Tue, 21 Apr 2009 04:02:46 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 53E343A6E18 for <dnsop@ietf.org>; Tue, 21 Apr 2009 04:02:46 -0700 (PDT)
Message-ID: <49EDA81E.2000600@ca.afilias.info>
Date: Tue, 21 Apr 2009 13:03:58 +0200
From: Shane Kerr <shane@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
CC: dnsop@ietf.org
References: <20090306141501.4BA2F3A6B4B@core3.amsl.com>
In-Reply-To: <20090306141501.4BA2F3A6B4B@core3.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Authenticated: True
Subject: Re: [DNSOP] 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 11:02:47 -0000

All,

Internet-Drafts@ietf.org wrote:
> 	Title           : DNSSEC Operational Practices, Version 2
> 	Author(s)       : O. Kolkman, M. Gieben
> 	Filename        : draft-ietf-dnsop-rfc4641bis-01.txt
> 	Pages           : 38
> 	Date            : 2009-03-06

I had a look through this and have a few comments.

First, key length:

                   An attacker breaking a 1024-bit signing key would
   need expend phenominal amounts of networked computing power in a way
   that would not be detected in order to break a single key.  Because
   of this, it is estimated that most zones can safely use 1024-bit keys
   for at least the next ten years.  A 1024-bit asymmetric key has an
   approximate equivalent strength of a symmetric 80-bit key.

(Typo: "phenominal" -> "phenomenal")

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.

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.


Second, private key storage:

   It is recommended that, where possible, zone private keys and the
   zone file master copy that is to be signed be kept and used in off-
   line, non-network-connected, physically secure machines only.

Then later...

   In general, keeping a zone file off-line will not be practical and
   the machines on which zone files are maintained will be connected to
   a network.  Operators are advised to take security measures to shield
   unauthorized access to the master copy.

The whole idea of offline storage for the zone itself is so fantastical
I hardly know where to begin! Has there ever in the history of DNS been
a zone where the master copy is only stored in a computer is not network
connected?

Of course it is theoretically possible. But I think at most a single
paragraph mentioning the possibility is enough to insure that the people
who have this level of paranoia about their DNS data will be able to let
their fevered imaginations run wild, without wasting the time of people
with actual deployments. :)

It might be more useful to recommend HSM - or at least encryption - for
private key data. I didn't see any references to this, and AFAIK
everybody does it (or feels guilty for not doing it).


Cheers,

--
Shane