IETF Logo Mail Archive

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

David Conrad <drc@virtualized.org> Thu, 03 April 2014 03:18 UTC

Return-Path: <drc@virtualized.org>
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 0500C1A0092 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 20:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 49sHeoIkm73S for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 20:18:20 -0700 (PDT)
Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id D5E381A008B for <dnsop@ietf.org>; Wed, 2 Apr 2014 20:18:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 6983D8554E; Wed, 2 Apr 2014 23:18:16 -0400 (EDT)
Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 14905-04; Wed, 2 Apr 2014 23:18:16 -0400 (EDT)
Received: from [10.188.215.178] (173006171106.wi-fi.kddi.com [106.171.6.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 855508554D; Wed, 2 Apr 2014 23:18:14 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_9F48478E-5574-4F6C-B6FF-C1C731C64192"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: David Conrad <drc@virtualized.org>
In-Reply-To: <alpine.LFD.2.10.1404021127070.7948@bofh.nohats.ca>
Date: Thu, 03 Apr 2014 12:18:06 +0900
Message-Id: <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>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/n3mYJB157hBK2GqOkSdCjrNf0qg
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, 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 03:18:26 -0000

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.

Regards,
-drc

v2.23.0 | Report a Bug | By Email