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

Ben Laurie <ben@links.org> Thu, 03 April 2014 10:14 UTC

Return-Path: <benlaurie@gmail.com>
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 123E41A01A8 for <dnsop@ietfa.amsl.com>; Thu, 3 Apr 2014 03:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 5ur3nVXsh_X5 for <dnsop@ietfa.amsl.com>; Thu, 3 Apr 2014 03:14:09 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id CB2FC1A0195 for <dnsop@ietf.org>; Thu, 3 Apr 2014 03:14:08 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id w8so1428633qac.12 for <dnsop@ietf.org>; Thu, 03 Apr 2014 03:14:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/8Z167rxZREKxTP6MlVKWLZDyP4KEtH+t+g8rfD2nlc=; b=bz/ztpJC2G90oF0iEHvZZIN73qGOCylhW6XKDeZbl/S2wDLVlJ+EVkBM6ZUIHmWvHp WE2vcvfaR9dwSlWoTWVzOMZFm9G+asKAZPHgwAA6iCxa//COm4GaDsVtSyVdfYwKcsPB hrmYUiihnFFxL2FAen5CqlrB4111hXJaUZk2rGj4zkgwnbU52I+pCo9vo8sEF/eLiv59 0qKSeE7Lgx8FrgYd2GX1GCNKzQ0OHrP4jfx01ld6iQYQWaIUB0ryvPcXd0lgdUC4NmF3 CZNSK7Sk20KWooP/r+RbQ/gwgMNWxljDVutxGOx8O7yOD0bATgRjxtwxWxFPMGR/FJ7+ bi6A==
MIME-Version: 1.0
X-Received: by 10.224.147.77 with SMTP id k13mr6453381qav.64.1396520044421; Thu, 03 Apr 2014 03:14:04 -0700 (PDT)
Sender: benlaurie@gmail.com
Received: by 10.96.157.137 with HTTP; Thu, 3 Apr 2014 03:14:04 -0700 (PDT)
In-Reply-To: <EC4417A6-758E-4F40-8126-81BE913F3EF6@virtualized.org>
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@mac.com> <1904697C-49EF-4F77-A71A-3E0E4FC16575@cox.net> <ED3B19A8-D4AD-46AC-84BD-9FD1C333EAF0@icsi.berkeley.edu> <alpine.LFD.2.10.1404021127070.7948@bofh.nohats.ca> <EC4417A6-758E-4F40-8126-81BE913F3EF6@virtualized.org>
Date: Thu, 3 Apr 2014 11:14:04 +0100
X-Google-Sender-Auth: 0vu_oHIVra8oUVvV5DZBhfLQUr8
Message-ID: <CAG5KPzyNKDnKOnbNOLg27XDvHtbHRippMGZ4nTdqPR=7LgiCTg@mail.gmail.com>
From: Ben Laurie <ben@links.org>
To: David Conrad <drc@virtualized.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/yJCEYE894H6-8RW1ufn9a016bto
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>, 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: Thu, 03 Apr 2014 10:14:13 -0000

On 3 April 2014 04:18, David Conrad <drc@virtualized.org> wrote:
> Paul,
>
> On Apr 3, 2014, at 12:38 AM, Paul Wouters <paul@nohats.ca> wrote:
>>>> 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.
>> Because we want to make security decisions based on a 1ms latency browser war?
>
> We want to make security decisions that actually improve security.
>
> Making a decision that results in people turning security off because the (perceived at least) performance impact is too large does not improve security.
>
> People are already doing insanely stupid things (e.g., not following TTLs) because they eke out a couple of extra milliseconds in reduced RTT per query (which, multiplied by the zillions of queries today's high content websites require, does actually make a difference).
>
> Having not looked into it sufficiently, I do not have a strong opinion as to whether increasing key lengths will result in people either not signing or turning off validation, but I believe it wrong to disregard performance considerations.

Before that question even becomes relevant, DNSSEC has to actually get
to the endpoints reliably, which we know it doesn't. By the time that
happens, the whole question of what key size should be used will
likely have a different answer anyway.