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

[Colm MacCárthaigh <[e-mail]>]

On Tue, Apr 1, 2014 at 5:31 PM, Mark Andrews <[e-mail]> 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.


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

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

-- 
Colm