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

Colm MacCárthaigh <colm@allcosts.net> Tue, 01 April 2014 15:15 UTC

Return-Path: <colm@allcosts.net>
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 50F831A07DE for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 08:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 3dgmW4QrQjFG for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 08:15:40 -0700 (PDT)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8D1A07AB for <dnsop@ietf.org>; Tue, 1 Apr 2014 08:15:39 -0700 (PDT)
Received: by mail-ob0-f181.google.com with SMTP id wp4so11174345obc.40 for <dnsop@ietf.org>; Tue, 01 Apr 2014 08:15:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tBhkiQMS3IJopsOweW2QxZWHJOG9rUWZ1YHyqdaUMGs=; b=cIlaHG6S18u2W5jJkbV+sx9JmgsiBBuMNexyLbnSNylbxyrYnp9qwQ9O4vZe0eSw2v tKLqvRtfwcdqEq+HRSCq4vQ4dXxcLRRaynpb4ZTgJ2BA3er0PMUj9XSBGO+Ae5JYsjXp Qruooz5GYCCgQ5YdwoTR5S5o/pi55LX5KEqH0iVSRvwl8fusjchtbqr9fdszBu4CvTbb ApKYC9O4l2Tmx/AQh+g9P8JfA7jbJ/1EZZwB+sthO4j+Y1NTMospke1OZhEWq4cCMuuO py7LAuhl7k/O0vzDAYpLQgNDxh9GRLGNDhX1mL1aOBeHFMMCi3soLw86z/kqyGiEAP71 LQCw==
X-Gm-Message-State: ALoCoQko1ylHyDnKLdR0e+DBRB2ROXBqKRF6wDwB07axeyghXvGVAZ398OZk5pLEetTq5QzZARrL
MIME-Version: 1.0
X-Received: by 10.182.124.66 with SMTP id mg2mr16018574obb.9.1396365336406; Tue, 01 Apr 2014 08:15:36 -0700 (PDT)
Received: by 10.76.20.164 with HTTP; Tue, 1 Apr 2014 08:15:36 -0700 (PDT)
In-Reply-To: <102C13BE-E45E-437A-A592-FA373FF5C8F0@ogud.com>
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>
Date: Tue, 1 Apr 2014 08:15:36 -0700
Message-ID: <CAAF6GDfGiB_GEVQ=igi4BeQsYBtQrqQ=uKZvAoJuSTLYL6PRyA@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: Olafur Gudmundsson <ogud@ogud.com>
Content-Type: multipart/alternative; boundary=f46d0444ed6ddaa69104f5fca343
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/NNYbEAcbsSlOdRoq3GwUp4nB22g
Cc: dnsop@ietf.org, =?ISO-8859-1?Q?Matth=E4us_Wander?= <matthaeus.wander@uni-due.de>, Bill Woodcock <woody@pch.net>
Subject: Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
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: Tue, 01 Apr 2014 15:15:41 -0000

On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson <ogud@ogud.com> 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.

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?

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

-- 
Colm