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

Mark Andrews <marka@isc.org> Wed, 02 April 2014 21:40 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 2CF101A03F0 for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 14:40:24 -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_47=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 zZVvB7WoLRpV for <dnsop@ietfa.amsl.com>; Wed, 2 Apr 2014 14:40:20 -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 E9CB91A03EF for <dnsop@ietf.org>; Wed, 2 Apr 2014 14:40:19 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id D70242383E1; Wed, 2 Apr 2014 21:40:03 +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 41E09160060; Wed, 2 Apr 2014 21:41:17 +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 DC22B16004A; Wed, 2 Apr 2014 21:41:16 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 32F5D1234256; Thu, 3 Apr 2014 08:40:01 +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> <20140402024919.GA97087@isc.org> <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=OdLYxOQ@mail.gmail.com>
In-reply-to: Your message of "Tue, 01 Apr 2014 22:24:34 -0700." <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=OdLYxOQ@mail.gmail.com>
Date: Thu, 03 Apr 2014 08:40:01 +1100
Message-Id: <20140402214001.32F5D1234256@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/YYneO4k30kvIhmvwZieVG7bRPZ4
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, Bill Woodcock <woody@pch.net>, "dnsop@ietf.org" <dnsop@ietf.org>, Evan Hunt <each@isc.org>, Phillip Hallam-Baker <hallam@gmail.com>, Matth?us Wander <matthaeus.wander@uni-due.de>
Subject: Re: [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 21:40:24 -0000

In message <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=OdLYxOQ@mail.gmail.com>
, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes:
> 
> On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <each@isc.org> wrote:
> 
> > 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.
> >
> 
> I don't think this makes much sense for a coherent resolver. If I were
> writing a resolver, the behaviour would instead be;  try really hard to
> find a valid response, exhaust every reasonable possibility. If it can't
> get a valid response, then if CD=1 it's ok to pass back the invalid
> response and its supposed signatures - maybe the stub will no better, at
> least fail open. If CD=0, then SERVFAIL, fail closed.

Guess what, resolvers do not work like that.  They are not required
to work like that.  They are however required to search if CD=0.
SERVFAIL should be a rare event.  SERVFAIL that gets fixed with
CD=1 and then validates successfull should be a even much rarer
event.

We know that there are cases where some of the authoritative servers
broken DNSSEC wise yet you want to optimise for the bad time / trust
anchor in the recursive server.

> Although CD means "checking disabled", I wouldn't actually disable
> checking, simply because that's stupid (I don't mean to be impolite, but I
> don't have a better word to use here). But by preserving the on-the-wire
> semantics of the CD bit, I'd preserve effectiveness as a cache, and pass on
> what's needed to validate even the failure cases.
> 
> 
> -- 
> Colm
> 
> --001a11c2a20c040b1504f60880b6
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
> On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <span dir=3D"ltr">&lt;<a href=3D"=
> mailto:each@isc.org" target=3D"_blank">each@isc.org</a>&gt;</span> wrote:<b=
> r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
> 1px #ccc solid;padding-left:1ex">
> On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote:<br>
> &gt; DNSSEC is a mitigation against spoofed responses, man-in-the-middle<br=
> >
> &gt; interception-and-rewriting and cache compromises. These threats are<br=
> >
> &gt; endpoint and path specific, so it&#39;s entirely possible that one of =
> your<br>
> &gt; resolvers (or its path) has been compromised, but not others. If all o=
> f<br>
> &gt; your paths have been compromised, then there is no recovery; only<br>
> &gt; detection. But that is always true for DNSSEC.<br>
> <br>
> Consider the scenario in which one authoritative server for a zone<br>
> has been compromised and the others have not, and that one happens to<br>
> have the lowest round-trip time, so it&#39;s favored by your resolver.=A0</=
> blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
> der-left:1px #ccc solid;padding-left:1ex">
> <br>
> If you query with CD=3D0, a validating resolver detects the problem<br>
> and tries again with another auth server. =A0It doesn&#39;t give up until<b=
> r>
> the whole NS RRset has failed.=A0</blockquote><blockquote class=3D"gmail_qu=
> ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
> ">
> <br>
> If you query with CD=3D1, you get the bogus data and it won&#39;t validate.=
> <br></blockquote><div>=A0</div><div>I don&#39;t think this makes much sense=
>  for a coherent resolver. If I were writing a resolver, the behaviour would=
>  instead be; =A0try really hard to find a valid response, exhaust every rea=
> sonable possibility. If it can&#39;t get a valid response, then if CD=3D1 i=
> t&#39;s ok to pass back the invalid response and its supposed signatures - =
> maybe the stub will no better, at least fail open. If CD=3D0, then SERVFAIL=
> , fail closed.=A0</div>
> <div><br></div><div>Although CD means &quot;checking disabled&quot;, I woul=
> dn&#39;t actually disable checking, simply because that&#39;s stupid (I don=
> &#39;t mean to be impolite, but I don&#39;t have a better word to use here)=
> . But by preserving the on-the-wire semantics of the CD bit, I&#39;d preser=
> ve effectiveness as a cache, and pass on what&#39;s needed to validate even=
>  the failure cases.=A0</div>
> <div><br></div></div><div><br></div>-- <br>Colm
> </div></div>
> 
> --001a11c2a20c040b1504f60880b6--
> 
> 
> --===============8417192190596279555==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============8417192190596279555==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org