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

Colm MacCárthaigh <colm@allcosts.net> Tue, 01 April 2014 17:50 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 545A41A09AE for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 10:50:27 -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 WQYFO9f3uoH9 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 10:50:25 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 299231A09A1 for <dnsop@ietf.org>; Tue, 1 Apr 2014 10:50:25 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id i7so11539486oag.23 for <dnsop@ietf.org>; Tue, 01 Apr 2014 10:50:21 -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=tlAPg6lEndxFlB9CPZXSWkVpU14dMjB6Zsc8UpE/JHA=; b=W2ItKW4oVItEeVpzElk9ZRWwsoFQHI/gOSGLhxFf6RMR2ds9amBjtXYrfX/bQeoFvL pccJ4gysEAeHMPF/o5xueGpsQBuUqmGxW7hmLrvmghEtWpL3AsrzcpH+j+6TjOE8lKIS fmMZZNJ7Xa8w9386kh/+YJf4fnsOsaqggvdayd/ZlM7uV/+aCoR3YuFS/JPpqR4ccd5+ DTl1VtJtLQVr/TUXVb4V9kD3uPZObRMUGSpxPfSD2X4d6DO9qzyOzoW2psWgQOUUrqHB SumeKJAwc6XLlaU8V01NEIoc4gBEbvA/DSWKivAR/KDek44HwbGGOsRC3gn3711wYiU7 RfbA==
X-Gm-Message-State: ALoCoQmI2NXU1Dw04GcN6KK/+gztI3FptFau6N3XvOikbsjg4QJwuvy8lFkCw4/PRmjfdFBKN3Y3
MIME-Version: 1.0
X-Received: by 10.60.62.34 with SMTP id v2mr15613360oer.37.1396374621349; Tue, 01 Apr 2014 10:50:21 -0700 (PDT)
Received: by 10.76.20.164 with HTTP; Tue, 1 Apr 2014 10:50:21 -0700 (PDT)
In-Reply-To: <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.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> <474B0834-C16B-4843-AA0A-FC2A2085FEFB@icsi.berkeley.edu> <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com>
Date: Tue, 1 Apr 2014 10:50:21 -0700
Message-ID: <CAAF6GDcs5-yEB=D1uRoMDLxUkxyO+aRz6L5NCTnaGAVnSHd+zA@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: multipart/alternative; boundary=089e0141a7ca47ce0704f5fecd1c
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/o1XEwpuTHgAIFGpkQzXI5MtoyMI
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Nicholas Weaver <nweaver@icsi.berkeley.edu>, =?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 17:50:27 -0000

On Tue, Apr 1, 2014 at 6:39 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote;wrote:

> On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver <nweaver@icsi.berkeley.edu
> > wrote:
>
>> Lets assume a typical day of 1 billion external lookups for a major ISP
>> centralized resolver, and that all are verified.  Thats less 1 CPU core-day
>> to validate every DNSSEC lookup that day at 2048b keys.
>>
>
>
> Yes, I agree, but you are proposing a different DNSSEC model to the one
> they believe in.
>
> The DNS world has put all their eggs into the DNSSEC from Authoritative to
> Stub client model. They only view the Authoritative to Resolver as a
> temporary deployment hack.
>


I think even in the imagined future of validating stub resolvers, there's
still value in centralized caching; it speeds up lookup times. There's no
sense in intermediates caching bad answers, especially since it can lead to
denial of service, so there's still some value in validating centrally too.

-- 
Colm