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

Paul Wouters <paul@nohats.ca> Thu, 03 April 2014 04:07 UTC

Return-Path: <paul@nohats.ca>
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 E9C911A0009 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 21:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gb8yf3GwHIaN for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 21:07:41 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 813DD1A0002 for <dnsop@ietf.org>; Wed, 2 Apr 2014 21:07:41 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 133E4813B1; Thu, 3 Apr 2014 00:07:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1396498057; bh=k5DwwUJwh6lVg2f/ytv9M9sQfl4xI3L93JqKQvHcwkE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aCWL0cX433KhiTfWiNtzVJsDgtX/SN7Gv9VJBZGUIiKbuucsEcssj27uObw8DqHaE rvacFSK1UKw6G8YPaYpLTvoFiE7Jf3FQiTszB3HJgLmSQpc+wGb7hFRYgUwQ2ZFSNf qu6KXqWURBlH4gCRkLLTSynBxjc6ovYDnLmVoMDc=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s3347a5b007906; Thu, 3 Apr 2014 00:07:36 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 3 Apr 2014 00:07:36 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: David Conrad <drc@virtualized.org>
In-Reply-To: <EC4417A6-758E-4F40-8126-81BE913F3EF6@virtualized.org>
Message-ID: <alpine.LFD.2.10.1404022353400.10007@bofh.nohats.ca>
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>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/fhvDQ2db7BvmDMRpaVgrP3uQoGQ
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
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 04:07:46 -0000

On Thu, 3 Apr 2014, David Conrad wrote:

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

I'm happy to hear the browser vendors taking DNS latency seriously, and
look forward to their contributions towards solving that, with solutions
such as http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query/

Perhaps they will even advise running resolvers on the stubs with
pre-fetching of low TTL records so they can get out of the DNS caching
business themselves.

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

Luckily, I think we've seen the chrome/speed pendulum is already
swinging back, and the browser vendors are seeing that users do
care about more than just about latency.

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

My previous email explained why I believe those performance considerations
were wrong.  I am not disregarding those out of principle, I'm disregarding
because I don't agree with the reasons offered. Big resolvers can add more
hardware without pain. End nodes like phones have plenty of CPU to use
up while waiting for latency, and then some.

Paul