IETF Logo Mail Archive

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

"Rose, Scott" <scott.rose@nist.gov> Wed, 02 April 2014 17:13 UTC

Return-Path: <scott.rose@nist.gov>
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 334FA1A02D0 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 10:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 pH0Lxy-zYuM7 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 10:13:43 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC701A02D2 for <dnsop@ietf.org>; Wed, 2 Apr 2014 10:13:38 -0700 (PDT)
Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB054.namprd09.prod.outlook.com (10.255.211.148) with Microsoft SMTP Server (TLS) id 15.0.908.10; Wed, 2 Apr 2014 17:13:32 +0000
Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.155]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.122]) with mapi id 15.00.0908.008; Wed, 2 Apr 2014 17:13:32 +0000
From: "Rose, Scott" <scott.rose@nist.gov>
To: S Moonesamy <sm+ietf@elandsys.com>
Thread-Topic: [DNSOP] Current DNSOP thread and why 1024 bits
Thread-Index: AQHPTnfOAMhm4SIXL0+1BjKoLx/Ns5r+VmMAgAAp6AWAABCDgA==
Date: Wed, 02 Apr 2014 17:13:31 +0000
Message-ID: <24554BB9-2EF4-43E9-BD32-92F8EA2FB5E4@nist.gov>
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> <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> <ED3B19A8-D4AD-46AC-84BD-9FD1C333EAF0@icsi.berkeley.edu> <6.2.5.6.2.20140402080754.0d35b798@resistor.net>
In-Reply-To: <6.2.5.6.2.20140402080754.0d35b798@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.6.219.138]
x-forefront-prvs: 0169092318
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(377454003)(199002)(189002)(51704005)(24454002)(93516002)(81542001)(83322001)(33656001)(47976001)(47736001)(97336001)(83072002)(50986001)(49866001)(86362001)(99396002)(19580405001)(74502001)(4396001)(15202345003)(56816005)(92566001)(81816001)(87936001)(19580395003)(97186001)(74662001)(59766001)(80022001)(76482001)(63696002)(85306002)(36756003)(80976001)(15975445006)(95416001)(76786001)(76796001)(85852003)(53806001)(77096001)(92726001)(31966008)(54356001)(2656002)(51856001)(20776003)(82746002)(54316002)(56776001)(81342001)(74876001)(90146001)(94316002)(81686001)(98676001)(47446002)(99286001)(65816001)(95666003)(93136001)(66066001)(74706001)(74366001)(77982001)(79102001)(69226001)(46102001)(83716003)(87266001)(94946001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB054; H:BLUPR09MB053.namprd09.prod.outlook.com; FPR:985CE57D.A5E6E4C4.70F571CB.80CBE373.203EA; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: nist.gov does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <00A7EF42336661409617268C88AE5F2E@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/lFRktVi_zgcLtdI5HF_y102CZQ4
Cc: dnsop WG <dnsop@ietf.org>, Edward Lewis <edlewis.subscriber@cox.net>
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 17:13:48 -0000

On Apr 2, 2014, at 12:06 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:

> 
>> 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.
> 
> For context, the discussion is about a ZSK.  There is a theory that it would take under a year and several million (U.S.) dollars to break 1024 bits.  It has been said (not on this mailing list) that an organization could do it within a shorter time.  It's not a good idea to wait for the demonstration as it can raise concerns about the entity which chose the key.
> 
> As a general comment I tried to find out which NIST recommendations are being discussed in respect to DNSSEC.  The requirements mentioned by Joe Abley refers to NIST SP 800-78.  That document is about "Cryptographic Algorithms and Key Sizes for Personal Identity
> Verification".  Is that the NIST recommendation on which this discussion is based?
> 

The only DNSSEC related NIST SP's are 800-57 and 800-81-2.  SP 800-57 is in 3 parts, part one is general key considerations and part 3 covers specific uses like DNSSEC.  It's showing its age though.  

The US Federal policy (now) is 2048 bit RSA for all uses, DNSSEC has a special exemption for 1024 bit ZSK's if desired (to reduce risks of fragmented packets).  I do know some .gov zones using 2048 bit KSK and ZSK's as local policies can call for stronger keys.  By 2015, .gov/mil zones should migrate to ECDSA.  Not sure if that will happen given the track record, but that is the roadmap.  

Scott

> Regards,
> S. Moonesamy  
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

===================================
Scott Rose
NIST
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

v2.23.0 | Report a Bug | By Email