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

[Mark Andrews <[e-mail]>]

In message <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=[e-mail]>
, =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= writes:
> 
> On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt <[e-mail]> 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:[e-mail]" target=3D"_blank">[e-mail]</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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============8417192190596279555==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]