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

Evan Hunt <each@isc.org> Wed, 02 April 2014 02:49 UTC

Return-Path: <each@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 4679D1A00B0 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 19:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.411
X-Spam-Level:
X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AxsqPigk9oSG for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 19:49:35 -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 5A6B31A00AA for <dnsop@ietf.org>; Tue, 1 Apr 2014 19:49:35 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7C6DAC94E0; Wed, 2 Apr 2014 02:49:19 +0000 (UTC) (envelope-from each@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1396406971; bh=z2g1/j0xDYo0gL5wFrw3xEAZqlfEOiR15m79ngYxihs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=BCOWjJi9ut2q2cg/wabN0sYcnbqfPhUdZDpvXiXSfLa+mUYiFvQ8K4kbCVIMuVeow jbvzpWtzVBuHpM1LKd8XTAuq54bI9kcqqrbWvElIjlx51ZejUmx1qSJtha4YECsr7Q Duvwj+FjmSUmxjx87gX4hdnp+S9VpYVDSd+IYf6w=
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 2 Apr 2014 02:49:19 +0000 (UTC) (envelope-from each@isc.org)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 4D1CC216C3B; Wed, 2 Apr 2014 02:49:19 +0000 (UTC)
Date: Wed, 2 Apr 2014 02:49:19 +0000
From: Evan Hunt <each@isc.org>
To: Colm MacC?rthaigh <colm@allcosts.net>
Message-ID: <20140402024919.GA97087@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> <CAAF6GDe=39bmVDOtox+9coaH7R06erm-JUK19ZwPEUVkxepKTg@mail.gmail.com> <20140402003159.B4B631228652@rock.dv.isc.org> <CAAF6GDdLs3V9JMa8jgD_asYqhmt=PCaBAmk4LO0JaX_q6q0UHQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAF6GDdLs3V9JMa8jgD_asYqhmt=PCaBAmk4LO0JaX_q6q0UHQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/KSn8CGmN9jFsjC5IkYEVrhxBPIE
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, Bill Woodcock <woody@pch.net>, "dnsop@ietf.org" <dnsop@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>, Matth?us Wander <matthaeus.wander@uni-due.de>
Subject: [DNSOP] CD (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 02:49:36 -0000

On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:
> DNSSEC is a mitigation against spoofed responses, man-in-the-middle
> interception-and-rewriting and cache compromises. These threats are
> endpoint and path specific, so it's entirely possible that one of your
> resolvers (or its path) has been compromised, but not others. If all of
> your paths have been compromised, then there is no recovery; only
> detection. But that is always true for DNSSEC.

Consider the scenario in which one authoritative server for a zone
has been compromised and the others have not, and that one happens to
have the lowest round-trip time, so it's favored by your resolver.

If you query with CD=0, a validating resolver detects the problem
and tries again with another auth server.  It doesn't give up until
the whole NS RRset has failed.

If you query with CD=1, you get the bogus data and it won't validate.
If you try again, you'll get the same bogus data out of the cache.
Use a different resolver, and if it happens to use the same auth
server, then the same thing happens again.

Your best chance of getting an answer that you can validate is to
send CD=0 to a recursive resolver that is itself validating.  If you get
SERVFAIL, *then* you try with CD=1, and if the result validates, you
know it was the resolver that was broken rather than the data.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.