Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

Olafur Gudmundsson <> Wed, 02 April 2014 02:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 15FC51A00A9 for <>; Tue, 1 Apr 2014 19:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GCWdJSJ1M0U3 for <>; Tue, 1 Apr 2014 19:45:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1C7441A00AA for <>; Tue, 1 Apr 2014 19:45:58 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (SMTP Server) with ESMTP id 65B4998EAF; Tue, 1 Apr 2014 22:45:54 -0400 (EDT)
X-Virus-Scanned: OK
Received: by (Authenticated sender: with ESMTPSA id 0F82299CB0; Tue, 1 Apr 2014 22:45:52 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E6B7F66-E5F0-4A7D-BEAE-2BEBC030A458"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Tue, 1 Apr 2014 22:45:52 -0400
Message-Id: <>
References: <> <> <> <> <>
To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= <>
X-Mailer: Apple Mail (2.1510)
Cc:, =?iso-8859-1?Q?Matth=E4us_Wander?= <>, Bill Woodcock <>
Subject: Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Apr 2014 02:46:00 -0000

On Apr 1, 2014, at 11:15 AM, Colm MacCárthaigh <> wrote:

> On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson <> wrote:
> Doing these big jumps is the wrong thing to do, increasing the key size increases three things:
>         time to generate signatures
>         bits on the wire
>         verification time.
> I care more about verification time than bits on the wire (as I think that is a red herring).
> Signing time increase is a self inflicted wound so that is immaterial.
>                   sign    verify    sign/s verify/s
> rsa 1024 bits 0.000256s 0.000016s   3902.8  62233.2
> rsa 2048 bits 0.001722s 0.000053s    580.7  18852.8
> rsa 4096 bits 0.012506s 0.000199s     80.0   5016.8
> Thus doubling the key size decreases the verification performance by roughly by about 70%.
> With those numbers; if the validating resolver uses speculative/optimistic concurrency [1] then jumping from 1024 to 4096 bits, the user-impact is that ~180us are added to the overall resolution time. Zero in the cached case. 

you are assuming one validation per question ? 
what if the resolver needs to to 10? that is 1.8ms, 

> There is an impact on the overall capacity of the resolver, though it's a function of cache-miss-rate (since cache hits need not be verified). Large centralised resolver operators may face some pressure (anyone doing validation locally is unlikely to notice), but is it sensible to compromise your zone security to accommodate that?

What is the security model ? 
without defining that we can not discuss "compromise" in practical terms. 
In my mind the question is what is the value of breaking key for "X", and the value depends on who/what "X" is. 
How valuable is it to anyone to break the key for vs ? 
As is more valuable they SHOULD use stronger keys at all times, but .com key is even more valuable.

In all system design we need to take into account where the system can be subverted, right now the 
registration part of DNS system is the weakest link, thus most cost effective way to gain hold of a domain is to 
divert the registration. 

Secondly what can someone do with "cracked" key and for how long?  

> [1] There's no need to wait for a response to be validated before recursing, a validating resolver can first recurse and later backtrack if the parent signature doesn't verify.

In the scope of things verification times are small compared to network delays but can add up if done as batch operation.