Re: [DNSOP] CD bit (was Re: Whiskey Tango Foxtrot on key lengths...)

Mark Andrews <marka@isc.org> Wed, 02 April 2014 03:24 UTC

Return-Path: <marka@isc.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 5DB151A00C3 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 20:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 tfuRdlWygKtz for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 20:24:10 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CBF141A00B6 for <dnsop@ietf.org>; Tue, 1 Apr 2014 20:24:10 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 317D5C9432; Wed, 2 Apr 2014 03:23:55 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1396409047; bh=hzqB31XDMbt5cX0vbwHUsIG/y3m1+QxATUCg62tiYoI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Z5tXFISNjTdKrv6aE0ygKIWjXWYeFKr+1l8GDHIcDV2P03iqt0R5nc8an/9sYKZs1 mKLuvdtWdM5DM2WN10gMoPoyPxFQQ4NnCmudDqg2S6gU+VNgUIh7DR1cFfm6trGT+Z wYFogzg59U0rWFoOlSsRpS+F+eF2HcZG46SDhlR4=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 2 Apr 2014 03:23:55 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A17FF160058; Wed, 2 Apr 2014 03:25:08 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 31E62160053; Wed, 2 Apr 2014 03:25:06 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C5EC8122A674; Wed, 2 Apr 2014 14:23:50 +1100 (EST)
To: Andrew Sullivan <ajs@anvilwalrusden.com>
From: Mark Andrews <marka@isc.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> <20140401223943.528B71226903@rock.dv.isc.org> <20140402025854.GB90415@mx1.yitter.info>
In-reply-to: Your message of "Tue, 01 Apr 2014 22:58:54 -0400." <20140402025854.GB90415@mx1.yitter.info>
Date: Wed, 02 Apr 2014 14:23:50 +1100
Message-Id: <20140402032350.C5EC8122A674@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/qIqWDQcw-MNmqZdFEuuQsBk5W7g
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] CD bit (was Re: 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: Wed, 02 Apr 2014 03:24:12 -0000

In message <20140402025854.GB90415@mx1.yitter.info>fo>, Andrew Sullivan writes:
> On Wed, Apr 02, 2014 at 09:39:43AM +1100, Mark Andrews wrote:
> 
> > Always set CD=1 is also bad advice.  Stub resolvers need to send
> > both CD=1 and CD=0 queries and should default to CD=0.  CD=1 should
> > be left to the case where they get a SERVFAIL result to the CD=0
> > to handle the case where the recursive server's clock is broken or
> > it has a bad trust anchor.
> 
> It strikes me that this argument has been hashed pretty well to death
> before, but just to refresh everyone's memory, there are several
> different strategies one can use here:
> 
> 1.  CD=1 all the time, and if you get into trouble consider the
> failure a feature.  Mark's argument (which has some merit) is that
> this is too strong, because if the stub gets the bogus answer, it
> can't "fall through" and pick up another one that might be good.
> 
> 2.  CD=1 mostly, and if you get a failure try falling back to CD=0.
> Maybe with CD=0, the recursive server will find you something that
> validates in order to get you on your way.
> 
> 3.  The opposite of (2), defauling to CD=0 (what Mark advocates).  
> 
> 4.  Give up on stubs and be a full service resolver all the time.
> 
> For 1-3, people may have a peek at RFC 6840, especially section 5.9
> and Appendix B.

And I pointed out before RFC 6840 was published that the appendix
was incomplete in its analysis.  You didn't want to reopen the
analysis, as it was a long discussion to get what was there, and
the wg, I suspect, was too fried to care one way or the other.  As
a result we have to deal with the fallout now.

> None of this, AFAICT, helps us at all with the 1024/2048 choice.

Actually it does as it shows that recursive servers need to validate.
If you are looking at workload you have to factor that into the
analysis.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org