[DNSOP] Current DNSOP thread and why 1024 bits

Edward Lewis <edlewis.subscriber@cox.net> Wed, 02 April 2014 13:30 UTC

Return-Path: <edlewis.subscriber@cox.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D61A01E4 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 06:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GMDoP6T2TAZl for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 06:30:47 -0700 (PDT)
Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net []) by ietfa.amsl.com (Postfix) with ESMTP id B63E81A01E6 for <dnsop@ietf.org>; Wed, 2 Apr 2014 06:30:47 -0700 (PDT)
Received: from eastrmimpo209 ([]) by eastrmfepo203.cox.net (InterMail vM. 201-2260-151-145-20131218) with ESMTP id <20140402133043.TKST30677.eastrmfepo203.cox.net@eastrmimpo209> for <dnsop@ietf.org>; Wed, 2 Apr 2014 09:30:43 -0400
Received: from [] ([]) by eastrmimpo209 with cox id l1Wi1n00X513AP0011Wjgz; Wed, 02 Apr 2014 09:30:43 -0400
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020209.533C1103.01DA,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=H/cFNZki c=1 sm=1 a=x3e9yDt9dqT69S6Zli6DPg==:17 a=gBr7uNU2Bm0A:10 a=G8Uczd0VNMoA:10 a=N659UExz7-8A:10 a=kviXuzpPAAAA:8 a=Ccln2k1ku-iqIxDJuC8A:9 a=pILNOxqGKmIA:10 a=x3e9yDt9dqT69S6Zli6DPg==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; auth=pass (PLAIN) smtp.auth=edlewis.subscriber@cox.net
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Edward Lewis <edlewis.subscriber@cox.net>
In-Reply-To: <knJn1n01E0xxhYs01nJoHJ>
Date: Wed, 2 Apr 2014 09:30:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1904697C-49EF-4F77-A71A-3E0E4FC16575@cox.net>
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>
To: "dnsop@ietf.org" <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/pcTD3Ai3f0ZCQgV0e7ntz1FClCA
Cc: Edward Lewis <edlewis.subscriber@cox.net>
Subject: [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:30:52 -0000

After a break of a few months I rejoined the DNSOP WG mail list. After the very first message I sent a complaint to the chairs over the tone and language.  I feel I should send a note about that to the open list itself.

It’s not that I have a puritan tongue.  It’s that such low-brow language, including the subject line’s obtuse reference to an obscene expression and finally to the out right vulgar expression in the thread call into doubt the level of professionalism of this WG.  It’s hard to defend the work that results from a group that exhibits juvenile behavior.  I realize that I am reacting to perhaps the writing of one person (perhaps, I never tried to verify the originator) and perhaps reacting to the interaction of a small group of individuals - even if some are well-intentioned here.  But I think that it is up to the WG to defend it’s stature and not accommodate this low level of discourse.

As to the matter at hand, I had been an operator of DNS services for about the past decade, designed the initial role out of DNSSEC in places, and ran a measurement experiment for a few years to quantify the choices.

I found that there are two primary reasons why 1024 bits is used in zone signing keys.

 One - peer pressure.  Most other operators start out with 1024 bits.  I know of some cases where operators wanted to choose other sizes but were told to “follow the flock.”

Two - it works.  No one has ever demonstrated a failure of a 1024 bit key to provide as-expected protection.

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.

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.

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.

It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation.  DNS operators want smaller, web performance wants quicker.  Putting all that together, the smaller key size makes sense.  In operations.

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.