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

Mark Andrews <marka@isc.org> Wed, 02 April 2014 00:32 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 3C6551A0037 for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 17:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level:
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 IgqSwtzW9nnH for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 17:32:17 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7361A001C for <dnsop@ietf.org>; Tue, 1 Apr 2014 17:32:17 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id C3A072383F1; Wed, 2 Apr 2014 00:32:02 +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 9CD79160060; Wed, 2 Apr 2014 00:33:15 +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 4342F160058; Wed, 2 Apr 2014 00:33:15 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B4B631228652; Wed, 2 Apr 2014 11:31:59 +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>
In-reply-to: Your message of "Tue, 01 Apr 2014 17:07:46 -0700." <CAAF6GDe=39bmVDOtox+9coaH7R06erm-JUK19ZwPEUVkxepKTg@mail.gmail.com>
Date: Wed, 02 Apr 2014 11:31:59 +1100
Message-Id: <20140402003159.B4B631228652@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/7PeSa9aiXszYwZHNeMHxJXB0H_s
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 00:32:19 -0000

In message <CAAF6GDe=39bmVDOtox+9coaH7R06erm-JUK19ZwPEUVkxepKTg@mail.gmail.com>om>, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writ
es:
> --089e011825440f264b04f604135f
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews <marka@isc.org> wrote:
> >
> > As I have said many times.  There is a myth that recursive servers
> > do not need to validate answers.  Recursive servers will always
> > need to validate answers.  Stub resolvers can't recover from recursive
> > servers that pass through bogus answers.
> 
> 
> 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.

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

> > So they resisted the idea of an authenticated Stub-client <-> Resolver
> > > protocol and they dumb down the crypto so their model will work.
> >
> > 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.
 
> -- 
> Colm
> 
> --089e011825440f264b04f604135f
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
> ue, Apr 1, 2014 at 3:39 PM, Mark Andrews <span dir=3D"ltr">&lt;<a href=3D"m=
> ailto:marka@isc.org" target=3D"_blank">marka@isc.org</a>&gt;</span> wrote:<=
> blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
>  #ccc solid;padding-left:1ex">
> As I have said many times. =A0There is a myth that recursive servers<br>
> do not need to validate answers. =A0Recursive servers will always<br>
> need to validate answers. =A0Stub resolvers can&#39;t recover from recursiv=
> e<br>
> servers that pass through bogus answers. =A0</blockquote><div><br></div><di=
> v>This too is going too far; of course they can, they can ask another recur=
> sive resolver.</div><div><br></div><blockquote class=3D"gmail_quote" style=
> =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 
> Always set CD=3D1 is also bad advice. =A0Stub resolvers need to send<br>
> both CD=3D1 and CD=3D0 queries and should default to CD=3D0. =A0CD=3D1 shou=
> ld<br>
> be left to the case where they get a SERVFAIL result to the CD=3D0<br>
> to handle the case where the recursive server&#39;s clock is broken or<br>
> it has a bad trust anchor.<br></blockquote><div><br></div><div>Defaulting t=
> o CD=3D0 renders DNSSEC, essentially, pointless. Resolvers, and the path be=
> tween resolvers and stubs, are the easiest components in the lookup chain t=
> o subvert.=A0<br>
> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
> er-left:1px #ccc solid;padding-left:1ex"><div class=3D"">
> &gt; So they resisted the idea of an authenticated Stub-client &lt;-&gt; Re=
> solver<br>
> &gt; protocol and they dumb down the crypto so their model will work.<br>
> <br>
> </div>DNSSEC is quite capable to protecting that path. =A0Why do you need<b=
> r>
> a second protocol.<br></blockquote><div><br></div><div>That statement is no=
> t consistent with setting CD=3D0 on that path.=A0</div></div><div><br></div=
> >-- <br>Colm
> </div></div>
> 
> --089e011825440f264b04f604135f--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org