Re: [DNSOP] key lengths for DNSSEC

Nicholas Weaver <nweaver@icsi.berkeley.edu> Wed, 02 April 2014 20:25 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DDD1A039C for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 13:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b2W6SLOppQ2 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 13:25:26 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4E01A03CA for <dnsop@ietf.org>; Wed, 2 Apr 2014 13:25:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3642F2C4038; Wed, 2 Apr 2014 13:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wxIRlp95yS5g; Wed, 2 Apr 2014 13:25:18 -0700 (PDT)
Received: from [172.20.10.2] (209.sub-70-208-138.myvzw.com [70.208.138.209]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1BC512C4044; Wed, 2 Apr 2014 13:25:15 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_84AC4BC9-C64A-4462-A881-7F8AF436FF6F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <1D0A45EF-E5D3-468D-BA08-E45FEF4399DE@dnss.ec>
Date: Wed, 02 Apr 2014 16:25:10 -0400
Message-Id: <3F49416C-2FE2-4A36-AD0B-3A52E7A7C3FB@icsi.berkeley.edu>
References: <78F386B0-BC6B-4159-B9D4-4BFEB10252A6@rfc1035.com> <1D0A45EF-E5D3-468D-BA08-E45FEF4399DE@dnss.ec>
To: đź”’ Roy Arends <roy@dnss.ec>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/nP_P5jOgmgIX827JSp547Rmlqlw
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, IETF DNSOP WG <dnsop@ietf.org>
Subject: Re: [DNSOP] key lengths for DNSSEC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 02 Apr 2014 20:25:30 -0000

On Apr 2, 2014, at 11:19 AM, đź”’ Roy Arends <roy@dnss.ec> wrote:
> 
> Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum.

The problem from the dns-op maximalist viewpoint is there is basically two magic numbers: 512B and ~1400B.  As someone who's measured this, the 512B is not a problem, but the 1400B "here be fragments" is.  Yet at the same time, the current 1024B ZSK/2048B KSK configuration on TLDs does blow through it: I reported in the previous thread how org's DNSKEY record already blew past that limit.


And even in that case, resolvers can handle "fragments don't work", albeit with a latency penalty.  So its not a "DNSSEC fails" point but simply "performance degraded".


So the real question is "do the common answers fragment", the ones with short TTLs that are accessed a lot, have a fragment problem.  With 2048b keys, they don't: the one that gets you is NSEC3, and that only blows up in your face on 4096b keys.  (But boy does it, those 3 RRSIGs get big when you're using 4096b keys).


And please don't discount the psychology of the issue.  If DNSSEC wants to be taken seriously, it needs to show it.  Using short keys for root and the major TLDs, under the assumptions that it can't be cracked quickly (IMO, we have to assume 1024b can be.) and that old keys don't matter [1], is something that really does draw criticism.



[1] IMO they do until validators record and use a 'root key ratchet': never accept a key who's expiration is older than the inception date of the RRSIG on the youngest root ZSK seen, or have some other defense to roll-back-the-clock attacks.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc