Re: [DNSOP] Current DNSOP thread and why 1024 bits

Nicholas Weaver <nweaver@icsi.berkeley.edu> Wed, 02 April 2014 13:44 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 459501A0202 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 06:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 s2Nq3vzf_kLN for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 06:44:35 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7C91D1A01D9 for <dnsop@ietf.org>; Wed, 2 Apr 2014 06:44:35 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id ED1482C4030; Wed, 2 Apr 2014 06:44:31 -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 dJMyWny-dpgC; Wed, 2 Apr 2014 06:44:27 -0700 (PDT)
Received: from [172.31.98.66] (unknown [216.9.110.10]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 733172C4021; Wed, 2 Apr 2014 06:44:27 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_46ED667C-28D6-4AA0-A555-548C56FFF8A0"; 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: <1904697C-49EF-4F77-A71A-3E0E4FC16575@cox.net>
Date: Wed, 2 Apr 2014 06:44:26 -0700
Message-Id: <ED3B19A8-D4AD-46AC-84BD-9FD1C333EAF0@icsi.berkeley.edu>
References: <0EA28BE8-E872-46BA-85FD-7333A1E13172@icsi.berkeley.edu> <53345C77.8040603@uni-due.de> <B7893984-2FAD-472D-9A4E-766A5C212132@pch.net> <102C13BE-E45E-437A-A592-FA373FF5C8F0@ogud.com> <474B0834-C16B-4843-AA0A-FC2A2085FEFB@icsi.berkeley.edu> <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com> <knJn1n01E0xxhYs01nJoHJ> <1904697C-49EF-4F77-A71A-3E0E4FC16575@cox.net>
To: Edward Lewis <edlewis.subscriber@cox.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/F-wvdT0wlpqYK6Wtk-Gk6Nl8g2I
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [DNSOP] Current DNSOP thread and why 1024 bits
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 13:44:40 -0000

The profanity is deliberate.  The same discredited performance arguments have come up for a decade+.  It gets very frustrating to see the same ignorance, again and again.


On Apr 2, 2014, at 6:30 AM, Edward Lewis <edlewis.subscriber@cox.net> wrote:
>> From these two main reasons (and you’ll notice nothing about cryptographic strength in there) a third very import influence must be understood - the tools operators use more or less nudge operators to the 1024 bit size.  Perhaps via the default settings or perhaps in the tutorials and documentation that is read.
> 
> Why do operators seem to ignore the input of cryptographers?  I can tell you that from personal experience.  Cryptographers, whenever given a straight question on DNSSEC have failed to give straight answers.  As is evident in the thread, theoretical statements are made and the discussion will veer off into recursive (really cache-protection) behaviors, but never wind up with a result that is clearly presented and defended.  In my personal experience, when I recommended 1024 bits, it was after consulting cryptographic experts who would just waffle on what size is needed and then relying on what we did in workshops 15 years ago.

Well, its because for the most part, cryptographers do seem to understand that DNSSEC is a bit of a joke when it comes to actually securing conventional DNS records.

And the NIST crypto recommendations have existed for years.  1024b RSA was "deprecated in 2010, eliminate completely in 2013".  There may be doubt in NIST now, but 2 years ago, to ignore the standard recommendations is foolish.

> What does it matter from a security perspective?  DNS messages are short lived.  It’s not like we are encrypting a novel to be kept secret for 100 years.  With zone signing keys lasting a month, 6 months, or so, and the ability to disallow them fairly quickly, what’s the difference between this so-called 80 or 112 bit strength difference?  Yes, I understand the doomsday scenario that someone might “guess” my private key and forge messages.  But an attack is not as simple as forging messages, it takes the ability to inject them too.  That can be done - but chaining all these things together just makes the attack that much less prevalent.

Do your resolvers have protection against "roll back the clock" attacks?  If not, you do not "gain protection" from the short-lived (well, really, a few month, they don't roll the actual key every 2 weeks) nature of the ZSK for root, .com, etc.

> Saving space and time does matter.  Roughly half the operators I studied would include a backup key on-line because “they could” with the shorted length.  And performance does matter - ask the web browser people.

Amdahl's law seems to be something that computer science in general always seems to forget.  The performance impact, both in size and cryptographic overhead, to shift to 2048b keys is negligible in almost all cases.  

And the step function in DNS cost, the "Internet can't do fragments" problem, doesn't really come into play at 2048b.

> It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation.  

Yes they have.  2048b.

> DNS operators want smaller, web performance wants quicker.  Putting all that together, the smaller key size makes sense.  In operations.

The real dirty secret.  

DNSSEC is actually useless for, well, DNS.  A records and the like do not benefit from cryptographic protection against a MitM adversary, as that adversary can just as easily attack the final protocol.

Thus the only actual use for DNSSEC is not protecting A records, but protecting cryptographic material and other similar operations: DANE is probably the best example to date, but there is also substantial utility in, e.g., email keys.  

DNSSEC is unique in that it is a PKI with constrained and enforced path of trust along existing business relationships.

Building the root of this foundation on the sand of short keys, keys that we know that are well within range for nation-state adversaries, from the root and TLDs is a recipe to ensure that DNSSEC is, rightly, treated by the rest of the world as a pointless joke.


> PS - Yes, some operators do use longer keys.  Generally, those that do have decent “excuses” (read: unusual use cases) and so they are not used in the peer pressure arguments.

And that does no good unless the upstream in the path of trust, starting at the root, actually use real length keys.

The difference between 2^80 and 2^100 effort is huge.  2^80 is in range today of nation states, and near the range of academics.

--
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