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

[Mark Andrews <[e-mail]>]

In message <CAAF6GDe=[e-mail]>, =?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 <[e-mail]> 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:[e-mail]" target=3D"_blank">[e-mail]</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: [phone]                 INTERNET: [e-mail]