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

Mark Andrews <marka@isc.org> Wed, 02 April 2014 02:51 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 311281A00AE for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 19:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.711
X-Spam-Level:
X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, 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 OBzEhs7Pd3jC for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 19:51:22 -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 30A091A0097 for <dnsop@ietf.org>; Tue, 1 Apr 2014 19:51:22 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7A81EC94E1; Wed, 2 Apr 2014 02:51:00 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1396407073; bh=f+XctU8ZK1GUkxjPylorfX3iNEo8skujHgmB+tknW9I=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=fuwODsSkbO173qmPrJZ9+8q/IBkuKqUVRqfElysNW2Yk0RaT0TanOkwXKr8TWeGrK FTJHTtQ9sEfvhL21ZgoSf6lyM90bYSpR4HVLDaYkEpIfsxxivANcy1I+FXgKXm9fgL v3zCBYBOAhyNNyeGYS066B16Fs0ZpUTKwW1r9InI=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 2 Apr 2014 02:51:00 +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 E7E79160058; Wed, 2 Apr 2014 02:52:13 +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 ED58F160053; Wed, 2 Apr 2014 02:52:12 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2A6011229CC3; Wed, 2 Apr 2014 13:50:55 +1100 (EST)
To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
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> <CAAF6GDe=39bmVDOtox+9coaH7R06erm-JUK19ZwPEUVkxepKTg@mail.gmail.com> <20140402003159.B4B631228652@rock.dv.isc.org> <CAAF6GDdLs3V9JMa8jgD_asYqhmt=PCaBAmk4LO0JaX_q6q0UHQ@mail.gmail.com>
In-reply-to: Your message of "Tue, 01 Apr 2014 18:25:12 -0700." <CAAF6GDdLs3V9JMa8jgD_asYqhmt=PCaBAmk4LO0JaX_q6q0UHQ@mail.gmail.com>
Date: Wed, 02 Apr 2014 13:50:54 +1100
Message-Id: <20140402025055.2A6011229CC3@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/FeOlDMyqra8CtInuCE0GS8ItoKU
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, "dnsop@ietf.org" <dnsop@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>, =?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: Wed, 02 Apr 2014 02:51:24 -0000

In message <CAAF6GDdLs3V9JMa8jgD_asYqhmt=PCaBAmk4LO0JaX_q6q0UHQ@mail.gmail.com>
, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes:
> 
> On Tue, Apr 1, 2014 at 5:31 PM, Mark Andrews <marka@isc.org> wrote:
> 
> > > This too is going too far; of course they can, they can ask another
> > > recursive resolver.
> >
> > Which also passes through bogus answers.  I will repeat stub resolvers
> > can't recover from recursive servers that pass through bogus answers.
> >
> 
> 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.

There is also the good answers mixed in with the bad answers coming
to the recursive server which is supposed to discard the bad answers
and wait for the good answer which will be in the query stream.

> > > Defaulting to CD=0 renders DNSSEC, essentially, pointless. Resolvers, and
> > > the path between resolvers and stubs, are the easiest components in the
> > > lookup chain to subvert.
> >
> > CD=0 tells the resolver to validate the answers it getsi if it is
> > validating.  It has NOTHING to do with whether you are validating
> > or not.  You have fallen for the myth that CD=1 indicates that you
> > intend to validate and that CD=0 means that you are not validating.
> > CD DOES NOT HAVE THOSE MEANINGS.
> >
> > DO=1 is the ONLY bit REQUIRED to be set if you are validating.
> >
> > If DO=1 is set you should assume the client may be validating.
> > Named assumes this when deciding if it will intentionally break
> > DNSSEC validation down stream.
> >
> 
> As you pointed out, if I set CD=1, I always expect a meaningful answer
> containing signatures that I can validate.  If I set CD=0, then an empty
> SERVFAIL response is valid. If I get SERVFAIL, how do I validate that it's
> a real error?

You re-check with CD=1.

> Your suggestion is to regress to the CD=0 case and re-check
> it (or maybe do your own recursion?). Why not just do CD=0 all along?

CD=1 is for bad trust anchors / clocks in the validating recusive server.
CD=0 is for attacker sending spoofed traffic at the recursive server.

Different fail/attack profiles, different query bits needed.

The recursive server sorts the wheat from the chaff and passes the
stub resolver the wheat.

> Now I agree that a resolver should always validate the signatures anyway,
> and if I were writing a caching resolver, I'd never cache rrsets that fail
> validation, even if the user has CD set to 1. But that's separate.
> 
> > > DNSSEC is quite capable to protecting that path.  Why do you need
> > > > a second protocol.
> > >
> > > That statement is not consistent with setting CD=0 on that path.
> >
> > I sugges that you go re-read all the DNSSEC RFC's if you believe
> > that because you are categorically WRONG.
> >
> 
> Please stay civil, and also please don't assume that I haven't read the
> DNSSEC RFCs.
>
> If you set CD=0, you can't authenticate the failure case, empty SERVFAILs
> can be spoofed or inserted towards the stub. And how do you disambiguate
> between SERVFAILs that are validation errors and other server failures?

You retry with CD=1, which I stated initially.  Note if the recursive
server is returning SERVFAILs to CD=0 it will be causing problems
for all its clients so will likely be fixed.  Additionally CD=0 helps
when the recursive server mis-classifies authoritative servers as not
supporting EDNS.

> Without some kind of resolver redundancy (so recovering via retrying
> another resolver) I don't see a way. Of course if all of your resolvers
> return SERVFAIL, you're left in the same situation - but again, if every
> path you have has been compromised, there is no escape.
> 
> But this can all be boiled down to;  As you've already written, you agree
> that CD=1 is necessary in the failure case - it's the only hope of
> authenticating the error. So why bother with CD=0 at all?

Because CD=1 does not get the good answers to the stub when the
responses to the recursive server are being spoofed.

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